An Aria table full of history you never delete wastes disk and slows backups, and aria_pack compresses it into a smaller, read-only copy. Budget about fifteen minutes for a small table, plus whatever a proper backup and a maintenance window cost you. The examples here target MariaDB 10.11.14, where aria_pack reports version 1.0.
You need the mariadb-server package, a readable Aria table, enough free space for temporary files, and permission to write beside the table. This changes table files and disrupts readers, so never point it at a table applications are still using.
These are ordinary read-only commands. You only need elevated privileges if your install hides the binary or package metadata:
$ command -v aria_pack
/usr/bin/aria_pack
$ aria_pack --version
aria_pack Ver 1.0 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.1The local manual page dates from May 2014, well behind the installed package, so treat the command's own --help as the final word on what your host actually supports. The core workflow below is shared by both.
Give aria_pack the table's .MAI index file; the matching data file carries the .MAD suffix. Never point it at a random file pulled from a database directory:
$ TABLE_DIR='/path/to/database'
$ TABLE_NAME='archive_events'
$ ls -l "$TABLE_DIR/$TABLE_NAME.MAI" "$TABLE_DIR/$TABLE_NAME.MAD"
-rw------- 1 mysql mysql ... /path/to/database/archive_events.MAD
-rw------- 1 mysql mysql ... /path/to/database/archive_events.MAISwap in the real directory and table name. If the files belong to the MariaDB service account you will need sudo, but root only fixes a permissions error; it does not make packing a live table safe.
Checkpoint: confirm both paths name the same table, and record their sizes before you change anything:
$ stat -c '%n %s bytes' "$TABLE_DIR/$TABLE_NAME.MAI" "$TABLE_DIR/$TABLE_NAME.MAD"Treat this as a maintenance operation. Stop the application, or otherwise block writes, and confirm nothing else (a backup job, an import, a repair) is touching the table. If a service manages it, use that service's own maintenance procedure rather than killing processes to clear a lock.
Back up the table before you pack it, and actually test the backup. The -b flag also tells aria_pack to keep the old table as table_name.OLD, but that is a convenience, not your backup:
$ sudo aria_pack --backup --test "$TABLE_DIR/$TABLE_NAME.MAI"
... packing test output ...--test rehearses the pack without touching the table. If it fails because the table is busy, stop and sort out your maintenance window instead of pushing on. Add --tmpdir=/path/to/space if it needs somewhere to stage temporary files, and make sure that directory exists and is writable by the account running the command.
This is the step that changes things. It makes the table read-only and rewrites its data, so check the table name once more before you press return:
$ sudo aria_pack --backup --verbose "$TABLE_DIR/$TABLE_NAME.MAI"
Compressing /path/to/database/archive_events.MAD: (... records)
- Calculating statistics
- Compressing file
...%Your record count and percentage will differ; the lines above just show the shape of the progress output. A successful run leaves the table packed. Without --force, the tool refuses to proceed if packing would make the table bigger, or if a temporary file already exists, so treat either refusal as something to investigate, not a reason to reach for --force.
If the table is briefly locked but you expect it to free up, --wait makes the tool wait and retry. Wrap the whole thing in a maintenance timeout so a stuck process cannot hold the window open forever.
aria_pack never touches the keys. Run aria_chk -rq on the index file straight after packing, exactly as the manual says:
$ sudo aria_chk -rq "$TABLE_DIR/$TABLE_NAME.MAI"
- check record delete-chain
- recovering (with keycache) Aria-table '/path/to/database/archive_events'
Data records: ...The exact progress text depends on the table. -r recovers it, -q picks the quick method. If the table is encrypted or uses a control file outside the default location, follow the server's existing Aria setup rather than borrowing options from an unrelated MySQL install.
Now run a read-only check. It updates check state but repairs nothing:
$ sudo aria_chk --check "$TABLE_DIR/$TABLE_NAME.MAI"
$ printf 'aria_chk status: %s\n' "$?"
aria_chk status: 0Zero means the check ran cleanly, not that your rows and indexes make sense at the application level. Only bring the service back once this check and your normal smoke test both pass.
Never try to insert into a packed table. To reverse the pack, stop writers again and run the unpack action through aria_chk:
$ sudo aria_chk -u "$TABLE_DIR/$TABLE_NAME.MAI"
$ sudo aria_chk --check "$TABLE_DIR/$TABLE_NAME.MAI"Keep the backup or the .OLD copy until the unpacked table has passed a check and an application-level test. If a pack or unpack gets interrupted, do not start deleting temporary or backup files by guesswork: stop the service if you need to, and restore the known-good copy or follow MariaDB's normal recovery procedure.
.MAD file instead of the matching .MAI gives the tool the wrong input; always hand it the index file.aria_chk -rq leaves the keys stale. Packing on its own is not the complete job./etc/my.cnf, /etc/mysql/my.cnf and ~/.my.cnf, in that order, under the [ariapack] group. Use --no-defaults for a reproducible diagnostic once you have checked no required site setting gets skipped by doing so..MAI and .MAD files were identified and backed up.aria_chk -rq rebuilt the keys.aria_chk --check returned status 0.