MariaDB Aria Engine: Crash-Safe MyISAM Alternative (2026)

The Aria engine is MariaDB’s attempt to make MyISAM crash-safe, but it’s not truly crash-safe in the way you’d expect; it’s more about recovering from crashes gracefully.

Let’s see it in action. Imagine you have a simple table:

CREATE TABLE products (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    price DECIMAL(10, 2)
) ENGINE=Aria;

Now, let’s populate it and then simulate a crash.

INSERT INTO products (name, price) VALUES ('Gadget', 19.99);
INSERT INTO products (name, price) VALUES ('Widget', 29.99);
-- Simulate a crash here: kill -9 <mariadb_pid>

After MariaDB restarts, you can query the table:

SELECT * FROM products;

You’ll find that both 'Gadget' and 'Widget' are still there. Aria writes data to a transaction log (the aria_log files) before writing it to the actual data files. If a crash occurs, Aria replays the transaction log upon restart to bring the data files back to a consistent state.

The core problem Aria solves is the fragility of MyISAM. MyISAM stores data in .MYD files and indexes in .MYI files. If the server crashes mid-write, these files can easily become corrupted, leading to data loss or unreadable tables. Aria addresses this by introducing a write-ahead logging mechanism.

Internally, Aria uses a log file (aria_log.XXXXXX) and a log sequence number (LSN) to track committed transactions. When a write operation occurs, the data is first appended to the log. Once the log entry is flushed to disk, the actual data file is updated. If the server crashes, Aria reads the aria_log files upon startup, identifies the last successfully written LSN, and re-applies any transactions that were logged but not fully written to the data files. This ensures that committed transactions are durable, even if the server crashes before the data files are updated.

The key configuration parameters for Aria are:

• aria_log_file_size: Controls the size of individual Aria transaction log files. Larger values can improve performance by reducing the number of log files, but increase recovery time after a crash. A common starting point is 128M.
• aria_log_control_file_size: Determines the size of the control file that tracks the Aria log files. This is usually much smaller than aria_log_file_size, often 1M.
• aria_checkpoint_interval: Specifies how often Aria should flush data to disk to create a checkpoint. This reduces the amount of log replay needed during recovery. A value like 10s (10 seconds) is typical.
• aria_page_cache_size: The size of the buffer pool used for caching Aria data pages. This significantly impacts read performance. 256M is a reasonable starting point for systems with ample RAM.

One thing most people don’t realize is that Aria’s "crash safety" is heavily dependent on the aria_log_force_index setting. When aria_log_force_index is ON (which is the default), Aria ensures that the index pages are flushed to disk before the data pages are considered committed in the log. This is crucial for maintaining index integrity. If this were OFF, you could have a scenario where data is updated, but the corresponding index entries are lost or inconsistent after a crash, leading to queries that don’t return expected results or errors.

The next concept you’ll likely encounter is how Aria interacts with other storage engines, particularly when performing operations like ALTER TABLE or when using TEMPORARY tables.