MySQL InnoDB 的redo log与 checkpoint

1.checkpoint

在InnoDB存储引擎内部，有两种Checkpoint，分别为：Sharp Checkpoint、Fuzzy Checkpoint

Sharp Checkpoint （全量检查点）发生在数据库关闭时将所有的脏页都刷新回磁盘，这是默认的工作方式，即参数innodb_fast_shutdown=1。但是若数据库在运行时也使用Sharp Checkpoint，那么数据库的可用性就会受到很大的影响。故在InnoDB存储引擎内部使用Fuzzy Checkpoint进行页的刷新，即只刷新一部分脏页，而不是刷新所有的脏页回磁盘。

Fuzzy Checkpoint（模糊检查点）：1、Master Thread Checkpoint；2、FLUSH_LRU_LIST Checkpoint；3、Async/Sync Flush Checkpoint；4、Dirty Page too much Checkpoint

在Innodb事务日志中，采用了Fuzzy Checkpoint，Innodb每次取最老的modified page(last checkpoint)对应的LSN，再将此脏页的LSN作为Checkpoint点记录到日志文件，意思就是“此LSN之前的LSN对应的日志和数据都已经flush到redo log

当mysql crash的时候，Innodb扫描redo log，从last checkpoint开始apply redo log到buffer pool，直到last checkpoint对应的LSN等于Log flushed up to对应的LSN，则恢复完成

如上图所示，Innodb的一条事务日志共经历4个阶段：

• 创建阶段：事务创建一条日志；

• 日志刷盘：日志写入到磁盘上的日志文件；

• 数据刷盘：日志对应的脏页数据写入到磁盘上的数据文件；

• 写CKP：日志被当作Checkpoint写入日志文件；

对应这4个阶段，系统记录了4个日志相关的信息，用于其它各种处理使用：

• Log sequence number（LSN1）：当前系统LSN最大值，新的事务日志LSN将在此基础上生成（LSN1+新日志的大小）；

• Log flushed up to（LSN2）：当前已经写入日志文件的LSN；

• Oldest modified data log（LSN3）：当前最旧的脏页数据对应的LSN，写Checkpoint的时候直接将此LSN写入到日志文件；

• Last checkpoint at（LSN4）：当前已经写入Checkpoint的LSN；

对于系统来说，以上4个LSN是递减的，即： LSN1>=LSN2>=LSN3>=LSN4.

具体的样例如下（使用show innodb status \G命令查看，Oldest modified data log没有显示）：

SHOW ENGINE INNODB STATUS

LOG 
Log sequence number 602763740   //redo 日志缓冲区中的LSN
Log flushed up to 602763740     //redo日志文件中的LSN
Pages flushed up to 584668961   //写入磁盘中的数据页对应的LSN
Last checkpoint at 555157885    //最近一个checkpoint对应的LSN


-- information_schema 库
select name,count from information_schema.innodb_metrics where name in ('log_lsn_current','log_lsn_last_checkpoint')

-- sys 库
select * from sys.metrics where variable_name in ('log_lsn_current','log_lsn_last_checkpoint')

2. 与Binlog的关系

由于mysql是插件式数据库，可能有多个引擎，想innoDB可以用redo日志进行实例恢复，但是其他引擎可能没有redo日志而依赖Binlog做实例恢复。所以，MySQL实例恢复以BinLog为准。

这两种日志有以下三点不同。

1.redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用。

2.redo log是物理日志，记录的是“在某个数据页上做了什么修改”；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给ID=2这一行的c字段加1 ”。

3.redo log是循环写的，空间固定会用完；binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

 

3.与Oracle恢复的差别

Oracle：先前滚Redo日志，再通过Undo日志回滚未提交的事务。

MySQL：1.对于活跃状态的事务，可以直接进行回滚。2.对于Prepare状态的事务，如果该事务对应的Binlog已经记录则提交，否则回滚事务。