Check and Repair Aria Tables Safely with aria_chk

A MariaDB table that crashed overnight is a job for aria_chk, which checks and repairs Aria tables without going through the SQL server at all. You will check a table, inspect its metadata, and make a controlled repair only when the check justifies it. Allow 10 to 20 minutes for a single table, plus time to arrange a maintenance window if the table belongs to a running service.

aria_chk works on the table files, not on a database name. The usual argument is the path to the table's .MAI index file, with or without that extension. Aria data normally sits beside it in a .MAD file. Do not run repair commands against a table that MariaDB or another process can write.

1. Check the installed command and package

This guide follows the local MariaDB package, mariadb-server 1:10.11.14-0ubuntu0.24.04.1. The installed utility reports version 1.3. Confirm the path and version before copying a command into a script:

$ command -v aria_chk
/usr/bin/aria_chk
$ aria_chk --version
aria_chk  Ver 1.3 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

The exact package revision and version line will vary on another host. If aria_chk is missing, stop and use the normal package-management process. Do not download a replacement binary into a database directory.

2. Locate a table and preserve the original files

Replace the example directory with the directory used by your MariaDB instance. Searching is read-only, but database directories may be private, so use elevated privileges only for the search if the account needs them:

$ find /var/lib/mysql -type f -name 'orders.MAI' -print
/var/lib/mysql/example/orders.MAI
$ ls -l /var/lib/mysql/example/orders.MAI /var/lib/mysql/example/orders.MAD

Keep a filesystem or database backup before repair. A repair changes the table files and can discard data that cannot be reconstructed. The --backup option makes a backup of the .MAD file during recovery, named with a timestamp and .BAK; that is useful, but it is not a substitute for a tested backup of both table files and their surrounding database state.

Checkpoint: You have the exact .MAI path, the matching .MAD file, a recoverable backup, and a maintenance window during which the table will not be used.

3. Run the default check first

Checking is the default action, so an explicit --check makes the intention clear. Run it as the account that can read and, because the default updates table state, potentially write the files:

$ aria_chk --check /var/lib/mysql/example/orders.MAI

The normal output is table diagnostics followed by a clean or error result. The exact wording depends on the table and utility build. A successful exit status is useful, but also read the reported result. For a read-only inspection that must not mark the table as checked, add --read-only:

$ aria_chk --check --read-only /var/lib/mysql/example/orders.MAI
$ printf 'exit status: %s\n' "$?"
exit status: 0

By default, --update-state is enabled. A check can mark a table crashed when it finds errors, or clean when it finds none and the old state was not clean. Use --skip-update-state when that state change is not wanted. Do not confuse the state marker with a repair: a clean check does not rewrite damaged rows.

4. Gather useful detail before choosing an action

Use --description for table information and --information for statistics during a check. Add --verbose when the normal output does not explain enough:

$ aria_chk --description --verbose /var/lib/mysql/example/orders.MAI
$ aria_chk --check --information --verbose /var/lib/mysql/example/orders.MAI

For a quicker routine pass, --fast checks only tables that were not closed properly, while --check-only-changed limits checking to tables changed since the last check. The default check is the better baseline when you are investigating an unexpected error. --medium-check is faster but the manual says it finds 99.99 percent of errors, not every error. Reserve --extend-check for difficult cases because it is deliberately thorough and can take much longer.

5. Repair only after stopping table access

Warning: Recovery is a state-changing operation. Stop the service or otherwise prove that no process can open the table, then take a backup. If the service cannot be stopped safely, use the server's own maintenance statements and procedures instead of editing live files.

The ordinary recovery method is --recover:

$ aria_chk --recover --backup /var/lib/mysql/example/orders.MAI

--recover can fix almost anything except non-unique unique keys, according to the local manual. If it reports that it cannot fix the data file, --safe-recover uses the older, slower method and can handle some cases that ordinary recovery cannot:

$ aria_chk --safe-recover --backup /var/lib/mysql/example/orders.MAI

Do not add --extend-check to a recovery command casually. During recovery it tries to obtain every possible row and may also find garbage rows. The manual describes that mode as suitable only when you are desperate. Likewise, --quick avoids modifying the data file and cannot fix a corrupted data file. It is not a general safety switch.

If a recovery fails, keep the original files and the generated backup. Record the complete diagnostic before trying another method. Do not repeatedly run different repair modes on the only copy of the table.

6. Verify the repaired table and return service

Run a fresh check after recovery, still while the table is unavailable to other processes:

$ aria_chk --check --information /var/lib/mysql/example/orders.MAI
$ printf 'check status: %s\n' "$?"
check status: 0

Compare the reported row and index information with the backup or the application's expectations. A zero status does not prove that an application-level transaction was recovered correctly. Once the file-level check is clean, start the service using its normal administrator procedure and test a read path before allowing writes. If the application reports missing or inconsistent data, stop writes again and restore the known-good backup rather than attempting more blind repairs.

Configuration can affect results. aria_chk reads options from /etc/my.cnf, /etc/mysql/my.cnf, and ~/.my.cnf, in that order, using the [aria_chk] group. Use --no-defaults to ignore option files for a controlled one-off invocation, or --print-defaults to see the arguments supplied by configuration. Review that output before troubleshooting a command that behaves differently from its visible arguments.

Done means