InnoDB crash recovery 过程和疑问

参考资料

• http://hedengcheng.com/?p=183#_Toc322971623
• https://dev.mysql.com/doc/refman/5.7/en/innodb-recovery.html

相关知识点

LSN

• LSN(log sequence number) 用于记录日志序号，它是一个不断递增的 unsigned long long 类型整数；
• 在 redo log 中，以 512 字节 block 对齐写入文件（最小单位 block，大小为 512 字节），通过LSN，可以具体的定位到其在redo log文件中的位置；
• 在 buffer pool 中，flush list 上的 page 按照修改这些 page 的 LSN 号进行排序。

checkpoint

• buffer pool 中的脏页刷盘时，从 flush list 尾部开始将数据页 fsync 到磁盘，并把最后一页的 LSN 记为 last checkpoint LSN，写入到 redo log 的头部；
• 也可以调用log_checkpoint() 完成 checkpoint 的写入，此时只会把 flush list 中最老的 LSN 写入到 redo log 头部，并不会刷脏页。

逻辑流程

1. 当正常 shutdown 实例时，会将所有的脏页都刷到磁盘，并做一次完全同步的 checkpoint；同时将最后的 lsn 写到系统表 ibdata 的第一个 page 中（函数fil_write_flushed_lsn）。在重启时，可以根据该lsn来判断这是不是一次正常的 shutdown，如果不是就需要去做崩溃恢复逻辑；

2. 表空间发现
   即找到从 last checkpoint LSN 后做过修改的表空间文件，避免打开所有的表空间。是通过 MLOG_FILE_NAME 来实现的：在一次 checkpoint 后第一次修改某个表的数据时，总是先写一条 MLOG_FILE_NAME 日志，记录 space ID 和文件名。

3. 应用 redo log
   打开上一步得到的表空间，依次将 page 读入内存；从 redo log file 中获取 last checkpoint LSN，应用所有大于这个 LSN 的 redo log（只有LSN大于数据页上LSN的日志才会被应用）

4. 遍历每个回滚段的 insert_undo_list 与update_undo_list，取出的undo，根据undo日志信息，重建事务；并且根据事务的不同状态：
   a. undo 事务状态为TRX_UNDO_ACTIVE，为活跃事务，TRX_ACTIVE
   b. undo 事务状态为TRX_UNDO_PREPARED -> TRX_PREPARED

5. 回滚处于 ACTIVE 状态的 DDL、DML 事务。而处于 PREPARE 状态的事务需要与 binlog 结合判断：
   a. 如果这个事务已经持久化到 binlog 中，即有 XID event，则不需要回滚这个事务
   b. 如果没有持久化到 binlog 中，则回滚

案例

分析一个 crash recovery 失败的异常案例：MySQL意外关闭，之后误删除 redo log，启动报错：

2020-05-28T10:35:26.800467+08:00 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 2437132
2020-05-28T10:35:26.800498+08:00 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 2437160
2020-05-28T10:09:06.785759+08:00 0 [Note] InnoDB: Starting crash recovery.
2020-05-28T10:09:06.809837+08:00 0 [ERROR] InnoDB: Page [page id: space=0, page number=7] log sequence number 8403155287 is in the future! Current system log sequence number 2437150.
2020-05-28T10:09:06.809917+08:00 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.
2020-05-28T10:09:06.811243+08:00 0 [ERROR] InnoDB: Page [page id: space=0, page number=4] log sequence number 8405956349 is in the future! Current system log sequence number 2437150.

原因：

• 意外关闭意味着有脏页没有 fsync 到磁盘，所有下一次启动需要做 crash recovery
• crash recovery 需要读取 redo log 中的 last checkpoint LSN，和 MLOG_FILE_NAME（记录table space ID 和文件名），然后对这些表空间的数据页从 checkpoint LSN 开始重做数据
• 但是由于删除了 redo log，启动时会重新创建 redo log，checkpoint LSN 会初始化成一个很小的值：2437132
• 而 MLOG_FILE_NAME 记录的 table space ID 的数据页上的 LSN 却比 last checkpoint LSN 还大，这是不应该的（正常来说，每个数据页有 LSN，在刷盘时，会从拥有最老 LSN 的数据页开始按顺序刷盘，然后把最后一个数据页的 LSN 记为 last checkpoit LSN，所以磁盘上的数据页的 LSN 肯定小于 last checkpoit LSN）。所以报这个错误。

疑问

关于 innodb_force_recovery=3 和 5 的区别在哪里？