14.18.1 The InnoDB Recovery Process InnoDB 恢复进程:

14.18.1 The InnoDB Recovery Process  InnoDB 恢复进程:


InnoDB crash recovery 有几个步骤组成:

1.应用redo log,Redo log 应用是第一阶段在初始化阶段执行,

在接收任何连接前。


如果所有的改变都从buffer pool 刷新到 tablespaces (ibdata* and *.ibd files)

在关闭或者crash 的时间点。


redo log 应用可以被跳过, 如果redo log files 在启动时候丢失,InnoDB 跳过redo log 应用。



删除redo logs 可以加速恢复过程,但不是推荐的,



即使如果一些数据的丢失是可以接受的。删除redo logs 只应在执行一个干净的关闭,

设置innodb_fast_shutdown set to 0 or 1.


回滚不完整的事务, 任何事务 在crash 或者fast shutdown 是活动的。


回滚的一个不完整的事务的时间可以是3或者4倍总量 一个事务活动的时间 在它被中断前,

依赖server 负载。


你不能cancel 事务,处于正在回滚的进程。在极端情况下,

当回滚事务语句需要很长的时间, 可能更快设置innodb_force_recovery 为3或者更大


Change buffer  合并:  应用changes 从change buffer（system tablespace的一部分）

到secondary indexes的leaf pages, 当index pages 是被读入到Buffer pool


清除: 删除标记删除的记录,对于任何活动事务不在可见


遵循redo log 应用不依赖redo log（除了日志写入）,以并行执行那些普通的处理

只有不完整事务的回滚是指定crash recovery.


insert buffer merge和purge 是执行的在普通的处理中。



在redo log 应用中,InnoDB 尝试接收连接连接尽可能的早,


降低停机时间。 作为crash recovery的一部分,InnoDB回滚任何事务 没有提交的

或者在XA 准备阶段当server crashed.


回滚时通过一个后台thread执行, 与新的连接的事务平行执行。


直到回滚完成,新的连接可能遇到locking 冲突 在回滚事务阶段




在大多数情况下, 如果MySQL server 被意外killed 在一个严重负载期间,


recovery 进程会自动发生,DBA不需要做任何事情,


MySQL 可能拒绝启动, 在那种情况下