InnoDB Redo Log 详解：原理、内容与崩溃恢复机制

Asthenian
291 阅读9分钟

InnoDB Redo Log 详解：原理、内容与崩溃恢复机制

本文深入探讨 MySQL 中 InnoDB 存储引擎的 Redo Log（重做日志），包括其定义、存储内容的详细解析、崩溃安全恢复机制，以及特定场景下的恢复流程，同时解释 Write Pos 和 Check Point 的含义及其区间的意义。本文旨在为数据库爱好者和开发者提供清晰的技术分析，特别对 Redo Log 内容的展示和重做过程进行了深入讲解。

一、Redo Log 是什么？

Redo Log 是 InnoDB 存储引擎用于实现事务持久性（Durability，ACID 中的 D）的一种日志机制。它记录了数据库中所有对数据的修改操作（物理或逻辑更改），以确保在系统崩溃后能够恢复数据到一致状态。Redo Log 的核心目标是提供 Crash-Safe 能力，即在数据库意外宕机后，保证已提交事务的更改不会丢失，未提交事务的更改可以被回滚。

主要特点：

  1. 物理-逻辑日志：Redo Log 记录的是对数据页的修改操作，既包含物理层面的页面更改（例如某个数据页的某个偏移量处的值变更），也包含逻辑层面的操作描述（例如插入、更新、删除等）。
  2. 顺序写入：Redo Log 采用顺序追加写入的方式，相比随机写入数据页，性能更高。
  3. 循环使用：Redo Log 文件大小固定，采用循环写入机制，旧日志会被覆盖（但需通过 Check Point 机制确保不会覆盖未持久化的日志）。

二、Redo Log 里面存了什么？

Redo Log 存储的是数据库事务对数据页的修改记录，具体内容包括以下字段（以伪结构表示）：

Redo Log 记录的结构示例

假设某个事务执行了 UPDATE users SET age = 30 WHERE id = 1，修改了某个数据页，Redo Log 可能生成如下记录（简化表示）：

Log Entry:
- LSN: 10000123                    // 日志序列号，标识日志位置
- Transaction ID: 45678            // 事务唯一标识
- Log Type: MLOG_WRITE_STRING      // 日志类型，表示写字符串操作
- Space ID: 5                      // 表空间 ID
- Page No: 1234                    // 数据页号
- Offset: 128                      // 数据页内偏移量
- Length: 4                        // 修改的数据长度
- Data: 0x0000001E                 // 修改后的值（age=30 的二进制表示）

字段详细说明：

  1. LSN（Log Sequence Number） ：单调递增的序列号，标识每条日志的顺序和位置，用于恢复时按序重放。

  2. Transaction ID：标识日志所属的事务，用于区分不同事务的修改。

  3. Log Type：描述操作类型，例如：

    • MLOG_WRITE_STRING：写入固定长度的数据。
    • MLOG_1BYTE：修改单个字节。
    • MLOG_REC_INSERT：插入记录。
    • MLOG_PAGE_CREATE：创建新页面（如 B+ 树分裂）。

  4. Space ID 和 Page No：定位修改发生的数据页，Space ID 标识表空间，Page No 标识具体页面。

  5. Offset 和 Length：指定数据页内修改的起始位置和数据长度。

  6. Data：记录修改后的实际值，通常是二进制格式。

实际内容的直观展示

以 UPDATE users SET age = 30 WHERE id = 1 为例，假设 age 字段存储在数据页 1234 的偏移量 128 处，占用 4 字节。Redo Log 记录的不是 SQL 语句，而是底层的物理修改：

  • 修改前：偏移量 128 处的值可能是 0x00000019（age=25）。
  • 修改后：偏移量 128 处的值变为 0x0000001E（age=30）。
  • Redo Log 记录：仅保存修改后的值 0x0000001E，以及修改的位置（Space ID、Page No、Offset）。

重做过程详解

在崩溃恢复时，InnoDB 通过重放 Redo Log 恢复数据页的状态。以下是重做过程的步骤，以上述示例说明：

  1. 定位数据页：

    • 根据 Space ID（5）和 Page No（1234），InnoDB 找到对应的数据页。
    • 如果数据页未加载到内存，InnoDB 会从磁盘读取（或初始化空白页）。

  2. 应用修改：

    • 根据 Offset（128）和 Length（4），定位数据页内的修改位置。
    • 将 Data（0x0000001E）直接写入偏移量 128 处，覆盖原有值。

  3. 验证一致性：

    • InnoDB 确保数据页的校验和（checksum）正确，确认修改成功。

重做的本质：直接赋值，而非反向 SQL

  • 直接赋值：Redo Log 记录的是修改后的值，恢复时直接将该值写入数据页的指定位置。这种方式是物理层面的操作，高效且无需解析 SQL。
  • 不执行反向 SQL：Redo Log 不记录 SQL 语句，也不会尝试执行反向操作（如 UPDATE ... SET age = 25）。这是因为 SQL 级别的操作需要解析和执行，效率低且可能引入复杂性。
  • 逻辑操作的处理：对于复杂操作（如 B+ 树分裂），Redo Log 记录的是逻辑操作的描述（例如“在页面 X 插入新节点 Y”），恢复时按相同逻辑重放，而非简单的数据赋值。

为什么不记录修改前的值？

Redo Log 只记录修改后的值，不记录修改前的值（修改前的值由 Undo Log 负责）。这是因为：

  • Redo Log 的目标是重放已提交事务的修改，只需知道最终状态。
  • Undo Log 负责回滚未提交事务，保存了修改前的值，用于恢复数据到事务开始前的状态。

三、如何实现 Crash-Safe 恢复？

InnoDB 的崩溃恢复（Crash Recovery）依赖 Redo Log 和 Undo Log，通过以下步骤实现：

  1. 读取 Redo Log：MySQL 启动时，InnoDB 扫描 Redo Log 文件，找到最后一个有效的 Check Point，从该点开始读取日志。
  2. 重放已提交事务：对于已提交的事务（通过事务状态或 Binlog 确认），InnoDB 重放 Redo Log 中的修改操作，将数据页恢复到崩溃前的状态。
  3. 回滚未提交事务：对于未提交的事务，InnoDB 利用 Undo Log 回滚这些操作，确保数据一致性。
  4. 检查一致性：恢复完成后，InnoDB 验证数据页和日志的一致性，确保数据库可用。

关键机制：WAL（Write-Ahead Logging）

InnoDB 遵循 WAL 原则，即在数据页修改写入磁盘之前，相关的 Redo Log 必须先写入磁盘。这保证了即使数据页未持久化，Redo Log 也能提供足够的信息来恢复数据。

四、Redo Log 写完，Binlog 在写过程中崩溃，如何恢复？

在 MySQL 中，Redo Log 和 Binlog 通过两阶段提交（Two-Phase Commit, 2PC）机制确保事务一致性。当 Redo Log 已写入（事务进入 PREPARE 阶段），但 Binlog 正在写入时发生崩溃，恢复流程如下：

  1. 检查事务状态：

    • InnoDB 检查 Redo Log 中的事务是否标记为 COMMIT。
    • 如果事务处于 PREPARE 状态，但 Binlog 中没有提交记录，说明 Binlog 未写完，事务未完成提交。

  2. 回滚未提交事务：

    • 对于没有在 Binlog 中找到提交记录的事务，InnoDB 利用 Undo Log 回滚这些事务的修改，恢复到事务开始前的状态。

  3. 重放已提交事务：

    • 如果事务在 Redo Log 中标记为 COMMIT，且 Binlog 中有提交记录，InnoDB 重放 Redo Log 中的修改。

  4. 结果：

    • 在此场景（Redo Log 写完，Binlog 未写完），事务未完成提交，会被回滚，数据库恢复到事务开始前的状态。

为什么这样设计？

两阶段提交通过 Redo Log 和 Binlog 的协调，确保主从复制和崩溃恢复的一致性。如果 Binlog 未写完，事务未标记为提交，主库回滚该事务，主从数据保持一致。

五、Write Pos 和 Check Point 是什么？

Redo Log 文件是固定大小的，采用循环写入方式，Write Pos 和 Check Point 是管理日志的关键指针。

  1. Write Pos：

    • 定义：当前 Redo Log 的写入位置，即最新日志记录的末尾。
    • 作用：随着事务执行，Write Pos 向前移动，指向下一个可写入位置。

  2. Check Point：

    • 定义：表示所有早于该点的日志对应的数据页修改已持久化到磁盘（即“脏页”已刷盘）。
    • 作用：Check Point 之前的日志不再需要用于恢复，可以被覆盖。InnoDB 定期推进 Check Point，回收日志空间。

Write Pos 和 Check Point 之间的区段

  • 从 Check Point 到 Write Pos：

    • 含义：活跃日志，包含尚未持久化到数据页的修改记录。
    • 用途：崩溃恢复时，InnoDB 重放这一区段的日志，恢复未刷盘的修改。

  • 从 Write Pos 到 Check Point：

    • 含义：可覆盖日志，表示这些日志对应的修改已持久化，或是空闲空间。
    • 用途：当 Write Pos 追上 Check Point，InnoDB 必须推进 Check Point（刷脏页），否则日志空间不足，数据库暂停写入。

图示说明

假设 Redo Log 文件是一个环形结构：

[Check Point] ----活跃日志---- [Write Pos] ----可覆盖日志---- [Check Point]
  • 活跃日志：需保留，用于崩溃恢复。
  • 可覆盖日志：可被新日志覆盖。

六、总结

Redo Log 是 InnoDB 实现事务持久性和崩溃恢复的核心机制，通过记录数据页的物理-逻辑修改，确保数据库在崩溃后恢复到一致状态。其关键点包括：

  • 存储详细的修改记录（Space ID、Page No、Offset、Data 等），支持精确重放。
  • 重做过程通过直接赋值修改后的值，高效且无需解析 SQL。
  • 通过 WAL 和两阶段提交，保证数据一致性和主从同步。
  • Write Pos 和 Check Point 管理日志写入和回收，活跃日志用于恢复，可覆盖日志可复用。
  • 在 Redo Log 写完但 Binlog 未写完的崩溃场景下，未提交事务会被回滚。

理解 Redo Log 的工作原理，不仅有助于优化 MySQL 性能，还能为故障排查和数据恢复提供支持。希望本文的详细分析能为你的数据库学习提供帮助！

avatar
文章
阅读
粉丝