(ib_logfile0 之外其它 redo log 文件的存储概览)
InnoDB 也是采用 WAL 的机制来保证事务的持久性, 从一定的意义上来说, redo 日志是顺序写, 写入速度很快. 数据库事务导致的数据修改进入到 InnoDB 存储层之后会将这些修改变更的记录存入 redo log 中, 然后将数据的变更写入内存中的 Page Pool 中. InnoDB 的后台线程会按照一定的规则 (例如定时或者脏页的数量达到一定的比例) 将脏页落盘, 落盘后会记录下来当前 redo Log 中有多少变更日志已经实际存储到了实际的数据 space 文件中. redo log 的总的写入量叫 LSN(Log Secquence Numer)日志序列号, 这个 redo log 变更实际写入到实际数据文件中的数量叫 checkpoint LSN, 表示的是有多少变更已经实际写入到了相应的数据文件中. 一旦数据库崩溃 InnoDB 开始恢复数据的时候, 先读取 checkpoint, 然后从 checkpoint 所指示的 LSN 读取其之后的 Redo 日志进行数据恢复, 从而减少 Crash Recovery 的时间.
比较前面两个概览图可以看到, checkpoint 信息只是存储在第一个 log 文件头中. 同时我们看到日志头中有 2 个 checkpoint block 域. InnoDB 是采用 2 个 checkpoint 了轮流写的方式来保证 checkpoint 的安全(并不是一次写 2 份 checkpoint, 而是轮流写). 也由于 Redo log 是幂等的, 应用一次和与应用两次都是一样的(在实际的应用 Redo 中, 如果当前这一条 log 的 lsn 大于当前 page 的 lsn, 说明这一条 log 还没有被应用到当前 page 中去). 所以, 即使某次 checkpoint block 写失败了, 那么崩溃恢复的时候从上一次记录的 checkpoint 点开始恢复也能正确的恢复数据库事务.
2.2. Log File Header
- (Log File Header 存储结构)
- Log Header Format:
这个字段以前用来标识当前 Log 文件属于哪个日志组, 现在新的意义是用来标识当前 Log 为文件的格式版本. 例如如果为 0 则表示这个 redo log 是有 5.7.9 以前的 MySQL 生成的.
PAD:
没有任何含义, 目前仅仅用来做一些对齐处理.
Start LSN:
这个字段用在 Clone 和 Archive 场景, 与一般的持久性, 崩溃恢复无关, 这里不做讨论.
Creator:
存储的是创建这个 log 文件创建者的名称的字符串.
Left Bytes:
目前没有任何含义, 仅仅是用来填充占位, 以便让这个 block 达到 512 字节大小.
2.3. Log Checkpoint
- (Checkpoint block 储存概览)
- checkpoint number:
checkpoint number 可以理解为 checkpoint 域写盘的次数, 每次写盘递增 1, 同时这个值取模 2 可以实现 2 个 checkpoint 域轮流写.
checkpoint LSN:
该字段标示小于这个 Checkpoint LSN 的日志记录都已经写入到了实际的数据文件中, Crash Recovery 系统从 Checkpoint LSN 之后的第一个 MTR 记录开始进行数据恢复.
checkpoint offset:
Checkpoint LSN 对应在 Log files 中的文件偏移量, 这个用来对 LSN 和 Offset 之间转换进行校准.
Buf size:
MySQL 系统内只对该字段执行了写入, 并为进行读取然后进行相应的处理. 它标识的是系统当前 Log buffer 的大小.
Left bytes:
目前没有任何含义, 仅仅是用来填充占位, 以便让这个 block 达到 512 字节大小. 但在这里最后 4 个字节用来存放该 checkpoint 域的 Checksum.
来源: http://blog.51cto.com/wangwei007/2287431