Read a MyISAM Log Safely with myisamlog

Find a file called myisam.log sitting in a data directory and the instinct is to run myisamlog over it to see what it says. Resist that instinct until you have read this: the plain command is not a passive viewer, it can write to your tables. This guide describes MariaDB 10.11 as installed here, specifically package version 1:10.11.14-0ubuntu0.24.04.1 and myisamlog version 1.4.

Allow about fifteen minutes, plus time to identify the correct log and its matching table files. You need a shell, a readable MyISAM log, and a maintenance plan if you intend to update or recover tables. Ordinary inspection commands do not need sudo. Do not run recovery against a live or valuable data set without a tested backup and a rollback plan.

1. Check the installed command

Confirm the executable and its version before relying on examples. This is read-only:

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

The exact platform line can differ. The installed manpage describes the MariaDB 10.11 command and documents the options used here. The binary also prints its version before trying to open a log, so a missing default log may be reported after the version line.

Checkpoint: Write down the absolute path to the log you have been authorised to inspect. Do not assume that a file called myisam.log belongs to the current server.

2. Inspect a named log without changing tables

Pass the log path explicitly. A named log avoids the confusing default: if no log argument is supplied, myisamlog uses myisam.log; the alias isamlog uses isam.log.

$ LOG_FILE='/var/lib/mysql/archive/myisam.log'
$ test -r "$LOG_FILE" && echo 'log is readable'
log is readable
$ myisamlog -i "$LOG_FILE"

Replace the placeholder path with the real file. The -i option asks for extra information before exit. Add -v when you need more detail about processing; it can be repeated for progressively more verbose output:

$ myisamlog -i -v "$LOG_FILE"
# output depends on the log contents and the selected tables

Do not treat a successful command as proof that the log matches the tables you care about. Check the file path, ownership, backup or restore context, and the table directory before acting on any output.

3. Understand the default operation before adding options

Here is the trap: the command's default operation is update, selected by -u. A plain invocation is not necessarily a passive log viewer. If the log is being applied to matching MyISAM tables, it can write changes.

Before using the update mode, stop and confirm all of the following:

There is no general undo command in myisamlog. Recovery means restoring the affected table files or backup, then repeating the operation correctly. If you only need to identify the tool and its syntax, use myisamlog -V or myisamlog -? rather than pointing an update command at production data.

4. Restrict an update to named tables

If you have approved an update, append one or more table names after the log filename. The manpage says that named tables limit which tables are updated:

$ myisamlog -u "$LOG_FILE" orders customers
$ printf 'exit status: %s\n' "$?"
exit status: 0

The table names are placeholders, not a promise that these names exist on your machine. Use the names expected by the log and the matching table files. Keep the log path quoted, and quote table names too if your local naming convention permits shell metacharacters.

Checkpoint: If the command returns non-zero, preserve its diagnostics and do not immediately retry with -r. First establish whether the path, table selection, permissions or log position is wrong.

5. Use recovery only as a planned repair

-r selects recovery. According to the installed documentation, recovery performs all writes and can perform updates and deletes, while errors are counted. That is a wider and more consequential operation than the default update mode.

Warning: Do not copy this command into a maintenance script without a named incident, a backup, and a tested restore path:

$ myisamlog -r "$LOG_FILE"
$ printf 'recovery exit status: %s\n' "$?"
recovery exit status: 0

The zero shown is an example of a successful process exit, not expected output for every log. It does not replace checking the affected tables. Recovery may write, update and delete data, so take a copy or snapshot before it and compare the result afterwards. If the recovery is not required, stop after the read-only checks instead.

6. Resume or narrow processing when the log is large

Use -c N to execute only a specified number of commands. Use -o offset to set a starting offset when your incident procedure gives you a known position:

$ myisamlog -u -c 100 -o 4096 "$LOG_FILE" orders
# the command processes at most 100 commands from offset 4096

These values are not guesses to make progress. An incorrect offset can skip records or begin in the middle of an operation. Record the source of the offset and command count in the incident notes. The -R record_pos_file record_pos option supplies a record-position file and record position when your recovery procedure uses those values.

-f N sets the maximum number of open files, -p N removes path components, and -w write_file specifies the write file. Treat each as a deployment-specific adjustment: the manpage does not provide a safe universal value, and changing path handling or output destinations without checking the surrounding table layout can make a repair harder to reproduce.

7. Diagnose the common failures

If no log path is supplied, the command tries myisam.log in the current directory. A missing-file error may therefore mean that the current directory is wrong, not that the server has no log. Check without changing anything:

$ pwd
$ ls -l -- "$LOG_FILE"
$ test -r "$LOG_FILE" && echo readable
readable

If a command fails after some processing, keep the full output and exit status. Do not assume that a failed update or recovery made no changes. Inspect the table files and use your backup or snapshot procedure if the data state is uncertain.

Use -i for extra information and -v, -vv or -vvv for increasing detail. The output is diagnostic, not a substitute for a backup. Avoid running an elevated shell merely because a path is inconvenient: use sudo only when the authorised recovery procedure requires access that the current account genuinely lacks.

Done means