15.18.1 The InnoDB Recovery Process（InnoDB宕机恢复执行）

InnoDB  consists of several steps:（宕机恢复的几个步骤）

• Applying the : Redo log application is the first step and is performed during initialization, before accepting any connections. If all changes were flushed from the  to the  (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.

• 翻译：应用redo log：应用Redo Log是恢复过程的第一步，并且整个过程在mysql初始化中，接口连接请求之前。如果在shutdown或者崩溃之前所有缓存数据都已经从BufferPool中刷到了表空间(磁盘)则这一步骤直接被跳过。并且如果redo log的文件在启动的时候找不到，那么应用redo log 这一步也会被跳过。

• 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  set to 0 or1.

• 翻译：即便在某丢失某些数据是可以被接收的情况下，删除redo logs 得以加快mysql恢复速度都是不推荐的操作。删除redo logs的操作应该仅仅在mysql执行过完整的shutdown情况下，完成的shutdown可以通过设置为0或者1(设置这两个的情况下，mysql在shutdown的时候会把所有的脏page刷到磁盘，而设置成2就不会刷到磁盘，但是mysql会在启动的时候根据redo log 进行修复)

•  incomplete : Any transactions that were active at the time of crash or . 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.

• 翻译：回滚一个不完整的事务：在崩溃或者fastshutdown时候的活跃事务。回滚一个不完整的事务所花时间大概在活跃事务存在的3倍或4倍，这取决于服务的负载

• 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  setting of 3or greater. See  for more information.

• 翻译：你不能取消一个正在回滚的事务。一个极端的例子，当一个事务的回滚预期知道需要很长的时间，如果想快点启动Innodb的话，你可以设置 为3或者更大（一般用在你其实知道怎么恢复数据的情况下，比如你只是修改了一个大表的字段，那么你可以先在启动的时候忽略Mysql的自动恢复，然后启动后人为恢复），详细请看

•  merge: Applying changes from the change buffer (part of the ) to leaf pages of secondary indexes, as the index pages are read to the buffer pool.

• 翻译：改变缓存合并：辅助索引改变的缓存（这里指的是Insert Buffer）应用合并到辅助缓存索引上，并读到缓冲池

• : 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.

翻译：这些应用Redo log的步骤不依赖Redo log与其他步骤可以同时并行操作（除了redo log的写入，而且仅仅在恢复过程中是串行的）。像Insert Buffer Merge 和 purge 都是可以并行的。

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.

翻译：在应用redo log恢复后，InnoDB试图尽可能快的接受请求链接，减少宕机时间。作为恢复操作中的一部分，InnoDB回滚宕机前任何没提交或者在XA 状态的事务。这种回滚的操作被后台的线程执行，并且与新请求链接的操作同时处理。那么在回滚操作完成之前，新连接请求可能会遇到恢复事务中的锁。

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  for the steps to troubleshoot such an issue.

翻译：在大多数情况下，甚至是在mysql服务在超负荷的活动下被意外的killed，mysql的恢复过程是自动的并且不需要DBA做任何操作。但如果是硬件错误或者InnoDB data发生严重的系统错误，那么Mysql可能会拒绝Start，这种情况请查看

For information about the binary log and InnoDB crash recovery, see .

翻译：更多关于二进制Binlog 和InnoDB 宕机恢复的信息请看.