(mysql.info.gz) Forcing recovery

(mysql.info.gz) InnoDB checkpoints
 
 15.9.1 Forcing Recovery
 -----------------------
 
 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
 TBL_NAME' or `InnoDB' background operations to crash or assert, or even
 the `InnoDB' roll-forward recovery to crash. Starting from MySQL
 3.23.44, there is an `InnoDB' variable that you can use to force the
 `InnoDB' storage engine 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 add the following line to the
 `[mysqld]' section of your option file before restarting the server:
 
      [mysqld]
      innodb_force_recovery = 4
 
 Before MySQL 4.0, use this syntax instead:
 
      [mysqld]
      set-variable = innodb_force_recovery=4
 
 The allowable non-zero values for `innodb_force_recovery' follow.  A
 larger number includes all precautions of lower numbers. If you are
 able to dump your tables with an option value of at most 4, then you are
 relatively safe that only some data on corrupt individual pages is
 lost. A value of 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.
 
    * `1' (`SRV_FORCE_IGNORE_CORRUPT')
 
      Let the server run even if it detects a corrupt page; try to make
      `SELECT * FROM TBL_NAME' jump over corrupt index records and pages,
      which helps in dumping tables.
 
    * `2' (`SRV_FORCE_NO_BACKGROUND')
 
      Prevent the main thread from running. If a crash would occur in
      the purge operation, this prevents it.
 
    * `3' (`SRV_FORCE_NO_TRX_UNDO')
 
      Do not run transaction rollbacks after recovery.
 
    * `4' (`SRV_FORCE_NO_IBUF_MERGE')
 
      Prevent also insert buffer merge operations. If they would cause a
      crash, better not do them; do not calculate table statistics.
 
    * `5' (`SRV_FORCE_NO_UNDO_LOG_SCAN')
 
      Do not look at undo logs when starting the database: `InnoDB' will
      treat even incomplete transactions as committed.
 
    * `6' (`SRV_FORCE_NO_LOG_REDO')
 
      Do not do the log roll-forward in connection with recovery.
 
 
 The database must not otherwise be used with any of these options
 enabled!  As a safety measure, `InnoDB' prevents users from doing
 `INSERT', `UPDATE', or `DELETE' when `innodb_force_recovery' is set to
 a value greater than 0.
 
 Starting from MySQL 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 set
 `innodb_force_recovery' to `3' to bring your database up without the
 rollback.  Then `DROP' the table that is causing the runaway rollback.
Info Catalog
(mysql.info.gz) Backing up
(mysql.info.gz) InnoDB checkpoints
automatically generated byinfo2html