MySQL在启动的时候,会进行前滚(利用redo log实现)和回滚(利用undo log和bin log实现)事物,来保证与前一次数据库服务关闭前的数据版本的最终一致性。
Crash Recovery的过程,可查阅参考文档一。
我们知道,不同的落盘机制影响着redo、undo、binlog以及数据本身的刷新策略。
1、Redo log
innodb_log_buffer_size控制着redo log的缓冲池大小,线程:master therad、参数:innodb_flush_log_at_trx_commit、以及缓存池的剩余容量触发(1/2大小)同时控制着redo log落盘的频率
2、Undo log
每做一次记录的修改操作,都会伴随着undo log的产生,修改操作所在的事物提交后,如果undo log不再被其他事物引用,就会被purge掉(正常情况下,会定期删除那些标记为删除并且不再被MVCC或rollback需要的undo页)。
注:insert操作的undo可以在所在事物提交后立即删除。相反,update和delete则仍然需要在一段时间内保存undo
3、binlog
sync_binlog,innodb_flush_log_at_trx_commit 控制着事物提交是如何影响binlog落盘的。
而innodb_support_xa同时限制着redo log和binlog。
4、Data
BP中脏页的刷新,在关闭时,由innodb_fast_shutdown控制。
innodb_fast_shutdown决定了InnoDB在关闭时需要做那些事情,可选取值:0、1、2
0、对所有undo页进行purge(数据库重启意味着所有的undo页都变为无用的了),对change buffer进行merge,刷新BP中的脏页。称之为“slow shutdown”或者“clean shutdown”,可能会耗费几分钟,甚至几小时。在进行MySQL大版本升降级时,需要如此设置。
1、默认值。在=0的操作的基础上,跳过那些一定要flush的操作(certain flush operations)仅刷新脏页,称之为“fast shutdown”。
2、不刷新BP中的脏页到磁盘上,仅刷新redo log buffer之后就直接shutdown,就好似MySQL是crash掉的。(下次重启时将会耗时在crash recovery的过程中)。一般用于紧急情况下,需要尽快关机的情况。
由于模式0在数据库重启时,不需要做crash recovery,所以启动速度是最快的;而模式1需要做少量的crash recovery,速度适中;反观模式2,则要耗费大量的时间在这个过程上。
总结如下:
取值 | purge all | merge change buffer | flush dirty pages |
---|---|---|---|
0 | √ | √ | √ |
1 | × | × | √ |
2 | × | × | 仅flush redo log buffer |
innodb_force_recovery决定了InnoDB在开启时需要做那些事情,可选取值:0~6。默认0
参考文档:
InnoDB crash recovery speed in MySQL 5.6