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¶
8.0.12-1: Feature ported from Percona Server for MySQL 5.7.
Command Line: Yes Config File: Yes Scope: Global Dynamic: Yes Variable Type: ULONG Range:
- With the default value,
assert, 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”.