shutdown or crash, redo log application is skipped. InnoDB  also skips redo log application if redo log files are missing at startup. 

•The current maximum auto-increment counter value is written to the redo log each time the value changes, which makes it crash-safe. During recovery, InnoDB  scans the redo log to collect counter value changes and applies the changes to the in-memory table object. 

For more information about how InnoDB  handles auto-increment values, see Section 15.6.1.6, “AUTO_INCREMENT Handling in InnoDB” , and InnoDB AUTO_INCREMENT Counter Initialization. 

•When encountering index tree corruption, InnoDB  writes a corruption flag to the redo log, which makes the corruption flag crash-safe. InnoDB  also writes in-memory corruption flag data to an engine- private system table on each checkpoint. During recovery, InnoDB  reads corruption flags from both locations and merges results before marking in-memory table and index objects as corrupt. 

•Removing redo logs to speed up recovery is not recommended, even if some data loss is acceptable. Removing redo logs should only be considered after a clean shutdown, with innodb_fast_shutdown  set to 0  or 1 . 

•Roll back of incomplete transactions 

Incomplete transactions are any transactions that were active at the time of unexpected exit 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 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 15.21.2, “Forcing InnoDB Recovery” . 

•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 to active transactions. 

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 transactions that were not committed or in XA PREPARE  state when the server exited. 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 required of the DBA. If a hardware failure or severe system error corrupted InnoDB  data, MySQL might refuse to start. In this case, see Section 15.21.2, “Forcing InnoDB Recovery” . 

For information about the binary log and InnoDB  crash recovery, see Section 5.4.4, “The Binary Log” . 

## Tablespace Discovery During Crash Recovery 

