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
files) at the time of the shutdown or crash, the redo log
application can be skipped. If the redo log files are missing at
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 ever be considered an option after a clean
shutdown is performed, with
innodb_fast_shutdown set to
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. 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 a long time, it may be faster
InnoDB with an
3 or greater.
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.19.2, “Starting
InnoDB on a Corrupted Database” for the
steps to troubleshoot such an issue.