InnoDB
crash recovery consists
of several steps:
Applying the redo log:
Redo log application is the first step and 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.
Removing redo logs to speed up the recovery process is not
recommended, even if some data loss is acceptable. Removing
redo logs should only be considered an option after a clean
shutdown is performed, with
innodb_fast_shutdown set to
0 or 1.
Rolling back incomplete transactions: Any transactions that were active at the time of crash or fast shutdown. The time it takes to roll back an incomplete transaction can be three or four times the amount of time a transaction is active before it is interrupted, depending on server load.
You cannot cancel transactions that are in the process of
being rolled back. In extreme cases, when rolling back
transactions is expected to take an exceptionally long time,
it may be faster to start InnoDB with an
innodb_force_recovery setting
of 3 or greater. See
Section 14.23.2, “Forcing InnoDB Recovery” for more
information.
Change buffer merge: Applying changes from the change 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.
The steps that follow redo log application do not depend on the redo log (other than for logging the writes) and are performed in parallel with normal processing. Of these, only rollback of incomplete transactions is special to crash recovery. The insert buffer merge and the purge are performed during normal processing.
After redo log application, InnoDB attempts to
accept connections as early as possible, to reduce downtime. As
part of crash recovery, InnoDB rolls back any
transactions that were not committed or in XA
PREPARE state when the server crashed. The rollback is
performed by a background thread, executed in parallel with
transactions from new connections. Until the rollback operation is
completed, new connections may encounter locking conflicts with
recovered transactions.
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.23.2, “Forcing InnoDB Recovery” for the
steps to troubleshoot such an issue.
For information about the binary log and InnoDB
crash recovery, see Section 5.4.4, “The Binary Log”.