Safely Inspect an Aria Transaction Log with aria_read_log

A crashed MariaDB server needs recovery, but aria_read_log lets you read the Aria log first so you know what a redo would touch. You end this guide able to inspect the log, find the directory the tool is actually using, and spot the exact point where recovery stops being a read and starts rewriting tables. The examples target MariaDB 10.11.14-0ubuntu0.24.04.1, whose aria_read_log reports version 1.5.

Allow about fifteen minutes. You need shell access to the MariaDB host and read access to the data directory. Inspecting the log is ordinary and needs no elevated privileges; applying it is a recovery operation that changes tables and needs an approved procedure, a backup and usually the account that owns the database files.

1. Confirm the installed command

Start with the binary that is actually on this host, so you are not copying syntax from a different MariaDB release:

$ command -v aria_read_log
/usr/bin/aria_read_log
$ aria_read_log --version
aria_read_log Ver 1.5 for debian-linux-gnu on x86_64
$ dpkg-query -W -f='${Package} ${Version}\n' mariadb-server
mariadb-server 1:10.11.14-0ubuntu0.24.04.1

2. Find the input directory

aria_read_log reads the Aria transaction log and its control file from the directory named by --aria-log-dir-path, also spelled -h. The installed help shows the default as the current directory, ., which is easy to get wrong. A typical MariaDB data directory is just an example below, not a value to guess:

$ ARIA_LOG_DIR='/var/lib/mysql'
$ sudo find "$ARIA_LOG_DIR" -maxdepth 1 -type f \
    \( -name 'aria_log_control' -o -name 'aria_log.*' \) -printf '%f\n'
aria_log.00000001
aria_log_control

That find is read-only. Swap in the directory your server actually uses, and check the result before running the tool itself. The control file is aria_log_control; the numbered aria_log.* files hold the actual log records. If the files live elsewhere, point at that directory explicitly rather than changing directory and trusting the default.

On a locked-down data directory, sudo may be needed just to list the files. It is not a requirement for the tool itself once your account can already read them, so do not widen permissions purely to make a diagnostic command run.

3. Display record headers without touching anything

Use --display-only, or -d, for the non-modifying inspection mode. Add --no-defaults so option-file settings in /etc/my.cnf, /etc/mysql/my.cnf or ~/.my.cnf cannot quietly change what the command does:

$ sudo aria_read_log --no-defaults \
    --display-only \
    --aria-log-dir-path="$ARIA_LOG_DIR"
<brief record-header output varies with the log>

The output is deliberately terse: record headers, not a full table dump, and the exact content depends on your log. A successful run never mentions applying REDO or UNDO records, and it never touches table files.

4. Add a readability check when you suspect corruption

The installed help documents --check for use alongside display-only mode, and it tells the tool to verify that a record is fully readable:

$ sudo aria_read_log --no-defaults \
    --display-only --check \
    --aria-log-dir-path="$ARIA_LOG_DIR"
$ printf 'exit status: %s\n' "$?"
exit status: 0

Status 0 just means this invocation ran cleanly; a non-zero status needs investigating alongside the diagnostic text it prints. Do not assume a damaged table is fixable just because its headers display fine. Keep a copy of the original log and table files before any recovery attempt.

5. Do not let a config file surprise you

Without --no-defaults, this program reads options in order from /etc/my.cnf, /etc/mysql/my.cnf and ~/.my.cnf, under the [aria_read_log] group. An option file can quietly set the log directory, flip on a mode or change a buffer size without any of it appearing in the command you typed.

$ aria_read_log --print-defaults
aria_read_log ...

That line is host-specific: treat it as diagnostic output, never as a recovery command. If an incident procedure needs a controlled config, use --defaults-file=PATH as the very first argument, and read that file before you trust it. Never point this at a file supplied by someone you do not trust.

6. Treat applying the log as a separate, riskier change

--apply, or -a, applies log records to tables and rewrites them. This is the line between inspection and recovery. The tool's own warning tells you to back up first, so stop and get an approved backup and rollback plan before you go anywhere near it:

# Example shape only. Do not run until the recovery plan is approved.
sudo aria_read_log --no-defaults \
    --apply \
    --aria-log-dir-path="$ARIA_LOG_DIR"

The installed 10.11.14 build also exposes separate redo and undo end-LSN controls that the local manpage, being older, does not show. Check aria_read_log --help on the host itself when an incident needs those newer options.