Handle Corrupted Tables¶
When a server subsystem tries to access a corrupted table,
the server may crash.
If this outcome is not desirable when a corrupted table is encountered,
set the new system
to a value which allows the ongoing operation to continue
without crashing the server.
The server error log registers attempts to access corrupted table pages.
Interacting with the
may work in conjunction with the
which considerably reduces
the effect of InnoDB subsystems
running in the background.
innodb_force_recovery variable is set to a low value
and you expect the server to crash,
it may still be running due to
a non-default value of the
For more information about the
see Forcing InnoDB Recovery
from the MySQL Reference Manual.
This feature adds a new system variable.
Version Specific Information¶
- 5.5.10-20.1 – Renamed.
0 - 1
1194 (ER_CRASHED_ON_USAGE) instead of crashing with an assertion failure, when used with
innodb_file_per_table. Once corruption is detected, access to the corrupted tablespace is disabled. The only allowed operation on a corrupted tablespace is
DROP TABLE. The only exception to this rule is when the option value is
salvage (see below).
This variable was renamed to
innodb_corrupt_table_action, beginning in release
5.5.10-20.1. The option name was
innodb_pass_corrupt_table in versions prior to that.
- 5.5.10-20.1 – Introduced.
- With the default value XtraDB will intentionally crash the server with an assertion failure as it would normally do when detecting corrupted data in a single-table tablespace.
- If the
warnvalue is used it will pass corruption of the table as
corrupt tableinstead of crashing itself. For this to work
innodb_file_per_tableshould be enabled. All file I/O for the datafile after detected as corrupt is disabled, except for the deletion.
- When the option value is
salvage, XtraDB allows read access to a corrupted tablespace, but ignores corrupted pages”.