1.1. Log & Checkpoint
Innodb的事务日志是指Redo log,简称Log,保存在日志文件ib_logfile里面。Innodb还有另外一个日志Undo log,但Undo log是存放在共享表空间里面的(ibdata文件)。
由于Log和Checkpoint紧密相关,因此将这两部分合在一起分析。
名词解释:LSN,日志序列号,Innodb的日志序列号是一个64位的整型。
1.1.1. 写入机制
1.1.1.1. Log写入
LSN实际上对应日志文件的偏移量,新的LSN=旧的LSN + 写入的日志大小。举例如下:
LSN=1G,日志文件大小总共为600M,本次写入512字节,则实际写入操作为:
l 求出偏移量:由于LSN数值远大于日志文件大小,因此通过取余方式,得到偏移量为400M;
l 写入日志:找到偏移400M的位置,写入512字节日志内容,下一个事务的LSN就是1000000512;
1.1.1.2. Checkpoint写入
Innodb实现了Fuzzy Checkpoint的机制,每次取到最老的脏页,然后确保此脏页对应的LSN之前的LSN都已经写入日志文件,再将此脏页的LSN作为Checkpoint点记录到日志文件,意思就是“此LSN之前的LSN对应的日志和数据都已经写入磁盘文件”。恢复数据文件的时候,Innodb扫描日志文件,当发现LSN小于Checkpoint对应的LSN,就认为恢复已经完成。
Checkpoint写入的位置在日志文件开头固定的偏移量处,即每次写Checkpoint都覆盖之前的Checkpoint信息。
1.1.2. 管理机制
由于Checkpoint和日志紧密相关,将日志和Checkpoint一起说明,详细的实现机制如下:

当事务执行速度大于脏页刷盘速度时,Ckp age和Buf age会逐步增长,当达到async点的时候,强制进行脏页刷盘或者写Checkpoint,如果这样做还是赶不上事务执行的速度,则为了避免数据丢失,到达sync点的时候,会阻塞其它所有的事务,专门进行脏页刷盘或者写Checkpoint。
因此从理论上来说,只要事务执行速度大于脏页刷盘速度,最终都会触发日志保护机制,进而将事务阻塞,导致MySQL操作挂起。
由于写Checkpoint本身的操作相比写脏页要简单,耗费时间也要少得多,且Ckp sync点在Buf sync点之后,因此绝大部分的阻塞都是阻塞在了Buf sync点,这也是当事务阻塞的时候,IO很高的原因,因为这个时候在不断的刷脏页数据到磁盘。例如如下截图的日志显示了很多事务阻塞在了Buf sync点:

附注:Innodb的日志保护机制实现可以参考log0log.c文件的void log_check_margins(v
网友评论