Oracle 5.0 Reference Manual page 1282

InnoDB: Rollback of uncommitted transactions completed
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Apply batch completed
InnoDB: Started
mysqld: ready for connections
If your database becomes corrupted or disk failure occurs, you must perform the recovery using a
backup. In the case of corruption, you should first find a backup that is not corrupted. After restoring the
base backup, do a point-in-time recovery from the binary log files using
restore the changes that occurred after the backup was made.
In some cases of database corruption it is enough just to dump, drop, and re-create one or a few
corrupt tables. You can use the
although
CHECK TABLE
Tablespace Monitor to check the integrity of the file space management inside the tablespace files.
In some cases, apparent database page corruption is actually due to the operating system corrupting
its own file cache, and the data on disk may be okay. It is best first to try restarting your computer.
Doing so may eliminate errors that appeared to be database page corruption.
14.2.5.1. The
InnoDB
crash recovery consists of several steps. The first step, redo log application, is performed
InnoDB
during the initialization, before accepting any connections. If all changes were flushed from the buffer
pool to the tablespaces
log application can be skipped. If the redo log files are missing at startup,
application.
The remaining steps after redo log application do not depend on the redo log (other than for logging the
writes) and are performed in parallel with normal processing. These include:
• Rolling back incomplete transactions: Any transactions that were active at the time of crash or fast
shutdown.
• Insert buffer merge: Applying changes from the insert buffer tree (from the shared tablespace) to leaf
pages of secondary indexes as the index pages are read to the buffer pool.
• Purge: Deleting delete-marked records that are no longer visible for any active transaction.
Of these, only rollback of incomplete transactions is special to crash recovery. The insert buffer merge
and the purge are performed during normal processing.
14.2.5.2. Forcing
InnoDB
If there is database page corruption, you may want to dump your tables from the database with
SELECT ... INTO
it is possible that the corruption might cause
background operations to crash or assert, or even cause
such cases, you can use the
engine to start up while preventing background operations from running, so that you are able to dump
your tables. For example, you can add the following line to the
before restarting the server:
[mysqld]
innodb_force_recovery = 4
innodb_force_recovery
permissible nonzero values for
all precautions of smaller 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 drastic because database pages are left in an obsolete state, which in turn may introduce more
corruption into B-trees and other database structures.
Backing Up and Recovering an
CHECK TABLE
naturally cannot detect every possible kind of corruption. You can use the
Recovery Process
(ibdata* and
Recovery
OUTFILE. Usually, most of the data obtained in this way is intact. However,
innodb_force_recovery
[1243] is 0 by default (normal startup without forced recovery) The
innodb_force_recovery
InnoDB
SQL statement to check whether a table is corrupt,
files) at the time of the shutdown or crash, the redo
*.ibd
SELECT * FROM tbl_name
InnoDB
[1243]
[1243]
1262
Database
mysqlbinlog
skips the redo log
InnoDB
statements or
roll-forward recovery to crash. In
option to force the
InnoDB
section of your option file
[mysqld]
follow. A larger number includes
and to
mysql
InnoDB
storage