PerlandFailure catalogue

The database found damaged data on disk

Fataldatabase_corrupted

A MySQL or PostgreSQL server read a page of its data files that is broken or incomplete, and stopped or refused the query rather than serve wrong data.

What the log shows

Written example2 lines
2026-11-05T11:08:37.661204Z 0 [ERROR] [MY-011906] [InnoDB] Database page corruption on disk or a failed file read of page [page id: space=7, page number=212]. You may have to recover from a backup.
2026-11-05T11:08:41.903377Z 14 [ERROR] [MY-011899] [InnoDB] [FATAL] Unable to read page [page id: space=7, page number=212] into the buffer pool after 100 attempts. The most probable cause of this error may be that the table has been corrupted.

Your log will have other names, versions and times. Search a line of it from all failures.

What it means

A database stores its tables in files made of fixed-size pages (16 KiB for MySQL’s InnoDB, 8 KiB for PostgreSQL). Each page carries a checksum or a header the database checks when it reads it. Here a page failed that check, or the file was shorter than it should be: part of the data on disk is not what the database wrote.

The database refuses to go on with a damaged page rather than return wrong data. MySQL usually stops the whole server; PostgreSQL fails the queries that touch the damaged table. The plugins or mods that use those tables stop working.

Why it happens

  • The database was stopped abruptly while writing, by a power loss, a crash of the machine, or its container being killed, on storage that does not guarantee what it acknowledged was written.
  • The disk is failing, or the file system under it has errors.
  • The disk filled up during a write, leaving files cut short.
  • The data files were copied or restored while the database ran, which gives a copy of files caught halfway through changes.
  • Rarely, a bug in the database or the storage driver.

How to fix

  1. Stop the database and back up its whole data folder as it is now, before any repair. Every recovery step can make things worse, and you want to be able to start over.
  2. The safest fix is to restore a backup or a dump taken before the damage. If you have one, restore it on a fresh, empty data folder.
  3. Without a backup, try to save what is readable:
    • MySQL: start it with innodb_force_recovery = 1 in its configuration (raise it one step at a time up to 3 only if it still does not start; values of 4 and above can damage the files for good, so use them only on a copy), dump everything with mysqldump, then load the dump into a new, empty database. Do not keep running on forced recovery.
    • PostgreSQL: dump each database with pg_dump; a table that cannot be read fails the dump, so dump the other tables one by one with pg_dump -t. Load the result into a new cluster.
  4. Check the disk afterwards (the machine’s dmesg or SMART data, the file system check). If it happens again, the disk may be failing: tell whoever runs the machine.

In Perland

A server’s database sidecar is a MySQL or PostgreSQL container next to the server, with its data in a Docker volume on the host. This issue appears in the sidecar’s diagnosis (the stack’s diagnosis with service mysql or postgres). With backups on, each backup holds a dump of the database that you can download and load into a fresh database by hand; Perland never loads it over a running database for you.

References

Details the diagnosis reports

Perland's server diagnosis returns this failure as the code database_corrupted with these parameters, each present only when the log names it.

ParameterMeaning
databaseWhich database printed it, `mysql` or `postgres`.

Log lines this page covers

  • Database page corruption on disk or a failed file read of page
  • Unable to read page [page id: …] into the buffer pool
  • invalid page in block … of relation …
  • could not read block … in file …: read only … of … bytes