Home / Alt manpages / innochecksum(1)

  • innochecksum(1)
  • User command
  • linux

Check an InnoDB Tablespace Safely with innochecksum

Before you touch a suspect .ibd file, innochecksum will tell you if it is actually corrupt without starting a repair or rewriting a single checksum. The examples use the installed MariaDB 10.11.14 command and a real system tablespace only to show the shape of the output. Allow about ten minutes for a small file, or longer for a large tablespace. You need a shell, a readable tablespace file, and enough privilege to obtain its exclusive lock.

This is an offline check. The file must not be open by a running MariaDB server. If the server has the tablespace open, stop at the checkpoint in step 2 and use a database-level check instead. Do not improvise a copy of a live file and treat that as a consistent backup.

1. Confirm the installed version and syntax

Start by checking which binary you will run. This matters because the installed help and the 2020 manual page do not spell every option the same way. On this host the package is mariadb-server-core 1:10.11.14-0ubuntu0.24.04.1, and the program reports version 10.11.14.

$ command -v innochecksum
/usr/bin/innochecksum
$ innochecksum --version
innochecksum Ver 10.11.14, for debian-linux-gnu (x86_64)
$ innochecksum --help
... output includes --count, --start-page, --end-page, --page, --page-type-summary

Run --help on the machine where the check will happen. In particular, this installed build calls the single-page option --page. The local man page also documents the older spelling --page-num and describes options removed in MariaDB 10.6, so do not copy an option from a different release without checking it first.

2. Make sure the file is offline

Identify the exact file and establish whether the database daemon is running. The following commands only inspect state:

$ pgrep -a 'mariadbd|mysqld'
$ stat -c '%n %s bytes' /path/to/tablespace.ibd

A blank process result is not the whole decision: confirm that no other service or container is using the same datadir. Then check the file path and permissions. The utility takes an exclusive lock while it works, so a lock failure is a useful safety boundary, not a reason to bypass the lock.

Checkpoint

Continue only when the server is stopped, the tablespace path is correct, and you have an agreed recovery plan. Checking a live tablespace is unsupported by the manual. For a tablespace that must stay open, use CHECK TABLE through the server instead.

3. Count pages before a full check

Run a page count first. Replace the placeholder with the real path, and keep the output in the terminal so you can record it alongside the file metadata:

$ sudo innochecksum --count /path/to/tablespace.ibd
Number of pages: 4864

The number above is an example from this machine's /var/lib/mysql/ibdata1, not a default for your file. --count reads the file and exits after reporting its page count. Root is not automatically required, but the datadir is commonly readable only by the database account or root. Use ordinary privileges when they work, and reach for sudo only when file permissions or lock policy demand it.

Check the exit status immediately if you are scripting the result:

$ sudo innochecksum --count /path/to/tablespace.ibd
Number of pages: 4864
$ printf '%s\n' "$?"
0

4. Run the checksum verification

With the file still offline, run the command with no write option. The normal behaviour calculates each page checksum and compares it with the stored value:

$ sudo innochecksum /path/to/tablespace.ibd
$ printf '%s\n' "$?"
0

A quiet successful run is a good sign here: this command is a verifier, not a report generator. A zero status means the check finished with no reported mismatch. Keep the terminal transcript and the file path alongside the time of the check. For a long-running scan, add --verbose; the installed program prints a progress indicator every five seconds.

$ sudo innochecksum --verbose /path/to/tablespace.ibd

For a narrower investigation, page numbers are zero-based. Use a range or one page once the full-file decision is understood:

$ sudo innochecksum --start-page=0 --end-page=0 /path/to/tablespace.ibd
$ sudo innochecksum --page=123 /path/to/tablespace.ibd

Do not confuse a page number with a byte offset. Use --count to establish the valid range, and never pick an end page beyond the file.

5. Add useful read-only detail

For a tablespace inventory, ask for counts of page types. This is still a read-only inspection:

$ sudo innochecksum --page-type-summary /path/to/tablespace.ibd
File::/path/to/tablespace.ibd
================PAGE TYPE SUMMARY==============
#PAGE_COUNT    PAGE_TYPE
...

The exact counts depend on the file. The output can include index, undo, inode, system, freshly allocated and other page types. Use --per-page-details when you need page-level information, or --log=/path/to/check.log when the output needs saving. Choose a new log path and check its ownership before making it part of an automated job.

These reporting options do not repair a damaged page. They help you describe what was checked and where a follow-up investigation should focus.

6. Handle locks and mismatches without making damage worse

If the command says it cannot lock the file, stop. Recheck the server state, open handles and path rather than adding a flag to defeat the lock. A file that changes while it is being scanned cannot give you a dependable offline result.

Warning

If a checksum mismatch is reported, preserve the original file and the command output. Do not use --write as a first response. That option rewrites checksum algorithms and takes an exclusive lock; the manual also describes --no-check as relevant when rewriting an invalid checksum. Rewriting changes evidence and can make recovery harder. The normal response is to restore the tablespace from a known-good backup, or start the server only under a deliberate recovery plan and use mariadb-dump to extract what remains readable.

The default mismatch allowance is zero, so the utility stops on the first mismatch. --allow-mismatches=N permits up to a specified number before termination, but it does not make those pages safe. Treat a non-zero mismatch count as a data-integrity incident and record the exact file, page if shown, version and exit status.

Done means

  • Version checked. The binary and MariaDB version were confirmed on the target host.
  • Offline confirmed. The tablespace was confirmed offline before the scan.
  • Page count recorded. --count recorded the file's page count and the full verification completed with the expected status.
  • Focused checks safe. Any focused page or page-type inspection used zero-based pages and read-only options.
  • Evidence preserved. A lock failure or mismatch was preserved for investigation, with no checksum rewrite attempted.