[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If there is database page corruption, you may want to dump
your tables from the database with SELECT INTO OUTFILE
,
and usually most of the data
is intact and correct. But the corruption may cause
SELECT * FROM table
, or InnoDB
background operations to crash or assert, or even the InnoDB
roll-forward recovery to crash. Starting from the InnoDB
version 3.23.44, there is a `my.cnf' option with which
you can force
InnoDB to start up, and you can also prevent background operations
from running, so that
you will be able to dump your tables. For example, you can set
set-variable = innodb_force_recovery = 4 |
The alternatives for innodb_force_recovery
follow.
The database must not otherwise be used with these options!
As a safety measure InnoDB prevents a user from doing INSERT
,
UPDATE
, or DELETE
when this option is > 0.
Starting from version 3.23.53 and 4.0.4, you are allowed to
DROP
or CREATE
a table even if
forced recovery is used. If you know that a certain table is causing
a crash in rollback, you can drop it.
You can use this also to stop a runaway rollback
caused by a failing mass import or ALTER TABLE
.
You can kill the mysqld process and
use the `my.cnf' option innodb_force_recovery=3
to bring your database up without the rollback.
Then DROP
the table which is causing the runaway rollback.
A bigger number below means that all precautions of lower numbers are included. If you are able to dump your tables with an option at most 4, then you are relatively safe that only some data on corrupt individual pages is lost. Option 6 is more dramatic, because database pages are left in an obsolete state, which in turn may introduce more corruption into B-trees and other database structures.
SELECT * FROM table
jump over corrupt index records and pages,
which helps in dumping tables;
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |