Safely Inspect an Aria Transaction Log with aria_read_log

You will finish with a read-only way to inspect an Aria transaction log, identify the directory the tool is using, and recognise the point at which recovery would start changing table files. The examples target the installed MariaDB package, version 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 relevant data directory. The inspection step is ordinary and does not need elevated privileges. Applying a log is a recovery operation that modifies tables, so it needs an approved maintenance 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 the host. This avoids 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

Checkpoint: if the command is missing, stop here. Installing another package or borrowing a binary from a different host can make recovery less safe. Use the package's normal administrative process to restore the expected utility.

2. Understand the input directory

aria_read_log reads the Aria transaction log and its control file from the directory supplied by --aria-log-dir-path, also written as -h. The installed help shows the default as the current directory, .. A typical MariaDB data directory is only an example, 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

The find command is read-only. Replace the placeholder with the directory used by this server, and check the result before running the utility. The control file is called aria_log_control; the numbered aria_log.* files hold Aria log records. If the files are elsewhere, use that directory explicitly rather than changing directory and relying on an easy-to-miss default.

On a protected data directory, sudo may be needed for the listing. It is not a requirement for the utility itself when your account can already read the files. Do not broaden permissions just to make a diagnostic command work.

3. Display record headers without applying recovery

Use --display-only, or -d, for the non-modifying inspection mode. Include --no-defaults while diagnosing a host so that options in /etc/my.cnf, /etc/mysql/my.cnf or ~/.my.cnf cannot silently change the command:

$ 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 intentionally brief: it comes from record headers rather than being a table dump. The exact records and formatting depend on the log. A successful run should not report that it is applying REDO or UNDO records, and it should not alter table files.

Checkpoint: keep the command read-only until you have captured the version, log directory and output. If the tool says it cannot find aria_log_control, check the path and permissions. For example, an empty test directory fails with an error about ./aria_log_control and exits with status 1. That means the input directory is wrong or incomplete, not that the log should be created by hand.

4. Add a readability check when investigating corruption

The installed help documents --check as an option used with display-only mode. Add it when you need the tool to check whether 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 means this invocation completed successfully. A non-zero status needs investigation alongside the diagnostic text. Do not infer that a damaged table can be repaired merely because headers can be displayed. Keep a copy of the original log and table files before any recovery attempt.

5. Keep configuration files from surprising you

Without --no-defaults, this program reads default options in order from /etc/my.cnf, /etc/mysql/my.cnf and ~/.my.cnf, using the [aria_read_log] group. An option file can therefore set the log directory, enable a mode or change a buffer without appearing in the command you are reviewing.

Use --print-defaults to see the arguments supplied by option files:

$ aria_read_log --print-defaults
aria_read_log ...

The exact line is host-specific. Treat it as diagnostic output, not as a recovery command. If an incident procedure requires a controlled configuration file, use --defaults-file=PATH as the first argument and review that file before proceeding. A path supplied by an untrusted person must not be used without checking its contents.

6. Treat applying the log as a separate change

--apply, or -a, applies log records to tables and modifies them. This is the destructive boundary in the workflow. The tool's own warning says to make a backup first. Stop and obtain an approved backup and rollback plan before using 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"

There is no general undo command for changes already applied to table files. Recovery is not a dry run, and --silent only reduces output; it does not make the operation safe or reversible. Options such as --start-from-checkpoint, --start-from-lsn, --end-lsn and --tables-to-redo narrow the recovery scope, but they still require a plan based on the actual log and tables. Do not invent LSN values or use a partial-table option as a substitute for a backup.

The installed 10.11.14 build also exposes separate redo and undo end-LSN controls in its help. The local manpage is older and does not show every newer spelling, so prefer aria_read_log --help on this host when an incident procedure needs those options.