InnoDB
crash recovery
consists of several steps:
The first step, applying the redo
log, is performed during initialization, before accepting
any connections. If all changes were flushed from the
buffer pool to the
tablespaces
(ibdata* and *.ibd
files) at the time of the shutdown or crash, the redo log
application can be skipped. If the redo log files are missing at
startup, InnoDB skips the redo log
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 (part of the system 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.
In most situations, even if the MySQL server was killed
unexpectedly in the middle of heavy activity, the recovery
process happens automatically and no action is needed from the
DBA. If a hardware failure or severe system error corrupted
InnoDB data, MySQL might refuse to start. In
that case, see Section 14.2.4.6, “Starting InnoDB on a Corrupted Database” for the
steps to troubleshoot such an issue.
© 2013, Oracle Corporation and/or its affiliates
User Comments
Add your own comment.