MySQL之Redo Log：确保数据持久性和崩溃恢复

MySQL Redo Log：确保数据持久性和崩溃恢复

1. 简介：Redo Log 的本质

Redo Log（重做日志）是 MySQL InnoDB 存储引擎中实现持久性的基石。它是一种物理日志，记录了对数据页所做的修改，而不是行级别的变更。这种“物理”特性使其在崩溃恢复时更加紧凑和高效。Redo Log 的核心原则是“预写式日志”（Write-Ahead Logging，WAL）：在将更改应用到数据文件之前先记录日志。这确保了即使数据库在修改后的数据页写入磁盘之前崩溃，已提交的事务也不会丢失。Redo Log 有效地体现了承诺：“已提交的内容一定会完成，即使在崩溃后也是如此。”

2. 核心概念和机制

2.1. 预写式日志 (WAL)

Redo Log 的基础是 WAL 原则：

1. 先写日志： 当事务修改数据时，InnoDB 首先将更改的记录写入 Redo Log Buffer（内存中）。

2. 提交需要日志刷新： 只有当 Redo Log 条目刷新到 Redo Log Files（磁盘上）后，事务才被视为已提交。innodb_flush_log_at_trx_commit 参数控制此行为。

3. 数据页稍后刷新： Buffer Pool 中修改后的数据页在后台异步刷新到数据文件。

WAL 的优点：

• 持久性： 保证已提交的事务在崩溃后存活。即使数据页未写入，Redo Log 也包含重新应用更改所需的信息。

• 性能： Redo Log 写入是顺序的（追加到文件），这比写入数据页所需的随机 I/O 快得多。

2.2. Redo Log 结构

Redo Log 由两个主要部分组成：

• Redo Log Buffer（内存）： 一个内存缓冲区，Redo Log 记录最初写入其中。其大小由 innodb_log_buffer_size 控制。

• Redo Log Files（磁盘）： 磁盘上的物理文件（通常命名为 ib_logfile0、ib_logfile1 等），Redo Log 记录持久化存储在其中。这些文件以循环方式写入。这些文件的数量和大小分别由 innodb_log_files_in_group 和 innodb_log_file_size 配置。

2.3. 日志序列号 (LSN)

LSN 是一个单调递增的、唯一的字节偏移量，用于标识 Redo Log 文件中 Redo Log 记录的位置。它对于以下方面至关重要：

• 日志记录标识： 每个 Redo Log 记录都有一个唯一的 LSN。 通过 LSN，InnoDB 能够准确无误地定位到 Redo Log 文件中的每一个 Redo Log 记录。 在崩溃恢复时，需要按顺序读取和重放 Redo Log 记录，LSN 保证了能够正确地找到并处理每一个日志记录，不会遗漏或错乱。 就像图书馆的书籍编号，LSN 确保每条 Redo Log 记录都有唯一的 “地址”。

• 数据页版本控制 (数据一致性判断): 每个数据页的头部也会记录一个 page_LSN，表示最近一次修改该数据页的 Redo Log 记录的 LSN 值。 page_LSN 非常重要，它用于在崩溃恢复时，判断数据页是否需要进行 Redo 操作，以及应该 Redo 到哪个版本。

  • 崩溃恢复时的数据页检查: 在崩溃恢复阶段，InnoDB 会读取数据页的 page_LSN，并与 Redo Log 中记录的 LSN 进行比较：

    • page_LSN < Redo Log LSN: 表示数据页上的修改操作可能尚未完全刷新到磁盘，需要根据 Redo Log 中的记录进行 Redo (重演) 操作，将数据页更新到 Redo Log 记录对应的状态。

    • page_LSN >= Redo Log LSN: 表示数据页已经包含了 Redo Log 记录对应的修改，无需进行 Redo 操作 (或者已经 Redo 过)。

page_LSN 就像数据页的 “版本戳”，记录了数据页最后更新的时间 (以 LSN 来衡量)。 通过比较 page_LSN 和 Redo Log LSN，InnoDB 能够精确地确定哪些数据页需要恢复，哪些数据页已经是最新状态，从而保证数据一致性。

• 检查点 (恢复起始点):** Checkpoint LSN 是 Checkpoint 机制的关键组成部分。 Checkpoint 操作会将当前数据库状态 (包括所有脏页和 Redo Log Buffer) 刷新到磁盘，并将当前的 LSN 值记录为 Checkpoint LSN。 Checkpoint LSN 标志着一个数据库状态的快照点。

• 崩溃恢复的起点: 在崩溃恢复时，InnoDB 不必从 Redo Log 的开头开始重放，而是从 Checkpoint LSN 开始，扫描和重放 Redo Log 记录。 因为 Checkpoint LSN 之前的 Redo Log 记录所对应的修改，都已经保证刷新到磁盘上的数据页了。 Checkpoint LSN 大大缩短了数据库的恢复时间，因为它减少了需要处理的 Redo Log 记录量。 Checkpoint LSN 就像一个 “恢复锚点”，指示了从哪里开始进行数据恢复。

• 保证 WAL 预写式日志 (核心机制支撑): LSN 是 Write-Ahead Logging (WAL) 预写式日志机制的核心支撑。 WAL 要求必须先将 Redo Log 写入磁盘，才能修改数据页。 LSN 保证了 Redo Log 的顺序性和持久性，使得 WAL 机制能够有效地工作。 每次修改数据页之前，都必须先获取一个更大的 LSN 并写入 Redo Log，确保 Redo Log 的 LSN 始终领先于数据页的 page_LSN，从而保证了数据持久性和崩溃恢复的可靠性。

结构：

• 结构: LSN 通常并非一个简单的整数，而是由多个部分组成，常见的结构包括：

  • Log File Number (日志文件编号): 标识 Redo Log 记录所在的 Redo Log 文件。 由于 Redo Log Files 通常以文件组形式存在 (例如 ib_logfile0, ib_logfile1, …)，这个编号用来区分不同的日志文件。

  • Log Offset (日志偏移量): 标识 Redo Log 记录在日志文件内的具体偏移位置 (字节数)。

    将日志文件编号和偏移量结合起来，就能在整个 Redo Log 文件组中精确定位到一个 Redo Log 记录。

• 生成与增长: LSN 由 InnoDB 存储引擎全局维护，并随着 Redo Log 的不断写入而单调递增。 每当生成一条新的 Redo Log 记录时，都会分配一个新的、更大的 LSN。 LSN 的增长反映了数据库事务操作的顺序和时间线。 可以将其理解为数据库操作的 “版本号”，LSN 值越大，代表着数据库状态越新。

2.4. Redo Log 记录格式

Redo Log 记录通常包含：

• 日志类型： 指定修改的类型（例如，MLOG_COMP_REC_INSERT、MLOG_REC_UPDATE、MLOG_1BYTE、MLOG_2BYTE 等）。

• 空间 ID 和页号： 标识已修改的数据页。

• 偏移量和长度： 指示页面内更改的位置和大小。

• 数据： 实际更改的字节（对于物理日志）或操作的表示（对于逻辑日志）。

• 事务 ID (trx_id): 标识事务.

• LSN： 日志序列号.

一个概念性的 C 结构体示例：

struct log_record {
  uint64_t lsn;        // 日志序列号
  uint32_t trx_id;     // 事务ID
  uint16_t type;       // 日志类型（MLOG_COMP_REC_INSERT等）
  byte data[];         // 重做数据
};

2.5. 迷你事务 (MTR)

MTR 是一组相关的 Redo Log 条目，表示对一个或多个页面的单个原子操作。例如，将一行插入 B+ 树可能涉及修改多个页面（叶节点、内部节点）。将这些更改分组到 MTR 中可确保在恢复期间应用所有更改或不应用任何更改。

2.6. Redo Log 写入过程

写入 Redo Log 条目的过程涉及多个步骤：

1. 生成 Redo Log 记录： 当事务修改数据页时，InnoDB 创建相应的 Redo Log 记录。

2. 写入 Log Buffer： 该记录将追加到内存中的 Redo Log Buffer。

3. 刷新到磁盘： 在以下情况下，Redo Log Buffer 将刷新到磁盘上的 Redo Log Files：

   1. 事务提交： 这是最重要的触发器，由 innodb_flush_log_at_trx_commit 控制。

   2. Log Buffer 已满： 当缓冲区大约半满时。

   3. 后台线程： 后台线程定期刷新缓冲区。

   4. 检查点： 检查点操作会触发刷新。

4. 三级缓冲机制:

   1. 用户线程生成 MTR (Mini-Transaction)

   2. Log Buffer (innodb_log_buffer_size)

   3. OS Cache (由 innodb_flush_log_at_trx_commit 控制)

   4. 磁盘文件

2.7. 组提交优化

• 合并多个事务的 fsync 操作。

• 提高 IOPS 利用率（尤其是在 HDD 上）。

• 由 binlog_group_commit_sync_delay（延迟时间窗口）控制。

在 MySQL 中，组提交（Group Commit） 是一种通过合并多个事务的日志刷盘操作来提升性能的机制。其核心目标是通过减少磁盘 I/O 次数，尤其是 fsync 操作的频率，从而提高事务提交的吞吐量。以下是具体实现和参数控制：

1. 组提交的核心原理

• 合并 **fsync**** 操作**： 默认情况下，每个事务提交时需要将 Redo Log 和 Binlog 分别刷盘（fsync）。组提交通过将多个事务的刷盘操作合并为一次，显著减少磁盘 I/O 次数

• 三个阶段：

  • Flush 阶段：将 Redo Log 的 prepare 状态数据刷盘，并将 Binlog 写入文件系统缓存（Page Cache）。

  • Sync 阶段：将多个事务的 Binlog 合并后一次性刷盘（fsync），这是性能优化的关键步骤。

  • Commit 阶段：将 Redo Log 状态更新为 commit，无需刷盘（因 Binlog 已持久化）

2. 参数控制

• binlog_group_commit_sync_delay：

  • 作用：定义事务组提交的 延迟时间窗口（单位为微秒）。

  • 效果：在等待该参数设置的时长内，收集多个事务的 Binlog，合并后一次性刷盘。例如设置为 1000（1 毫秒），则每毫秒触发一次组提交

  • 适用场景：适用于高并发写入场景，通过增加延迟换取更高的吞吐量，但需权衡响应时间。

• binlog_group_commit_sync_no_delay_count：

  • 作用：定义触发刷盘的 事务数量阈值。

  • 效果：当队列中的事务数达到该阈值时，立即触发刷盘，忽略 binlog_group_commit_sync_delay 的设置

2.8. innodb_flush_log_at_trx_commit

这个关键参数控制持久性和性能之间的权衡：

• 0****（最不安全，性能最高）： Redo Log 条目被写入日志缓冲区，并每秒刷新到操作系统的缓存。崩溃可能会丢失最多一秒的事务。

• 1****（最安全，默认，推荐）： Redo Log 条目在每次事务提交时写入日志缓冲区并刷新到磁盘（使用 fsync）。保证不丢失已提交的事务。

• 2****（中等安全，中等性能）： Redo Log 条目在提交时写入日志缓冲区并写入操作系统的缓存。刷新到磁盘会发生，但不一定立即使用 fsync。操作系统（不仅仅是 MySQL）崩溃可能会丢失事务。

3. 检查点机制

Redo Log 文件的大小是有限的。检查点机制可防止它们被填满并加快崩溃恢复速度。

• 目的：

  • 缩短恢复时间： 恢复只需要应用最后一个检查点之后的 Redo Log 条目。

  • 回收日志空间： 一旦相应的脏页已刷新到磁盘，检查点之前的 Redo Log 条目就不再需要。

• 过程：

  • 确定检查点 LSN： 通常是缓冲池中最早的修改的 LSN（最早的脏页）。

  • 刷脏页： 将检查点 LSN 之前的所有脏页（Buffer Pool 中已修改但尚未刷新到磁盘的数据页）刷新到磁盘。

  • 记录检查点信息： 将检查点 LSN 和其他信息写入 Redo Log 文件和数据文件头。

  • 回收 Redo Log 文件空间: 检查点 LSN 之前的 Redo Log 文件空间可以被标记为“可重用”。

• 检查点类型:

  • Sharp Checkpoint: 在数据库正常关闭时执行，刷新所有脏页。恢复速度最慢，但数据最安全。

  • Fuzzy Checkpoint (模糊检查点): 在数据库运行期间定期执行，只刷新部分脏页。

    • Master Thread Checkpoint: 由 Master Thread 定期触发。

    • LRU Checkpoint: 淘汰 LRU 链表尾部的脏页时触发。

    • Async Flush Checkpoint: 限制脏页比例过高时触发。

    • InnoDB Shutdown Checkpoint: 关闭时执行，类似于 Sharp Checkpoint。

4. 崩溃恢复

当 MySQL 崩溃并重新启动时，InnoDB 使用 Redo Log 执行崩溃恢复：

1. 确定起始位置： 从数据文件头读取检查点 LSN。

2. 扫描 Redo Log： 从检查点 LSN 开始，扫描 Redo Log 文件。

3. 重放 Redo Log (Redo)： 对于每个 Redo Log 记录，InnoDB 重做对数据页的物理修改。

4. 应用 Undo Log (Undo)： 对于崩溃时尚未提交的事务，InnoDB 使用 Undo Log 回滚更改。

优化:

• 使用哈希表按页面对 Redo Log 条目进行分组，减少恢复期间的随机 I/O。

• 通过比较页面的 FIL_PAGE_LSN 和检查点 LSN，跳过已刷新到磁盘的页面。

5. 电商场景应用

• 订单支付持久性: Redo Log 确保支付记录和订单状态更新永久保存。

• 库存扣减可靠性: Redo Log 确保库存扣减操作的持久性，避免超卖。

• 用户账户资金安全: Redo Log 保证账户资金操作的持久性。

• 事务 ACID 特性保障: Redo Log 与 Undo Log、锁机制、MVCC 等共同保证事务的 ACID 特性。

• 秒杀库存扣减保障（例子）

/* 事务提交策略 */
SET GLOBAL innodb_flush_log_at_trx_commit=1;  -- 实时刷盘保证数据安全

START TRANSACTION;
UPDATE stock SET quantity=quantity-1 
WHERE item_id=1001 AND quantity>0;
COMMIT;  -- 触发Redo日志同步写入

• 分布式事务恢复 (XA 例子)

-- 使用XA事务协调多个数据库
XA START 'order_transaction';
UPDATE orders SET status=2 WHERE order_id=1001;
XA END 'order_transaction';
XA PREPARE 'order_transaction';  -- 写入Redo日志

-- 崩溃恢复时自动重做已Prepare的事务

6. 备份与恢复

6.1. 时间点恢复 (PITR)

1. 全量备份 + Redo 日志

# 备份时记录LSN
mysqldump --single-transaction --master-data=2 > backup.sql

# 恢复时应用Redo
mysqlbinlog --start-position=457890 /var/lib/mysql/ib_logfile* | mysql -uroot -p

1. 与 Binlog 协同工作

6.2. 崩溃恢复流程

1. 前滚（Redo）阶段

   1. 从 Checkpoint LSN 开始重做所有日志

   2. 通过 LSN 顺序保证恢复一致性

2. 回滚（Undo）阶段

   1. 扫描未提交事务的 Undo Log 进行回滚

   2. 维护事务原子性

7. 性能调优参数

8. 监控与诊断

8.1. 关键状态指标

SHOW ENGINE INNODB STATUS\G
-- LOG段重点指标
Log sequence number 117766351395  -- 当前LSN
Log flushed up to   117766351395  -- 刷盘LSN
Last checkpoint at  117766351386  -- Checkpoint LSN

8.2. 性能分析工具

# 使用innodb_ruby解析日志文件
innodb_space -s ibdata1 -T test/t1 -p 3 page-dump | grep -i lsn

# 监控日志写入吞吐
iostat -x 1 | grep -E 'Device|sda'  # 观察磁盘写入量

9. 总结与最佳实践

• 理解 WAL 原理: 深入理解预写式日志 (WAL) 的工作原理。

• 合理配置 Redo Log 参数: 根据应用场景合理配置 Redo Log 参数。

• 监控 Redo Log 状态: 监控 Redo Log 的写入速度、刷新频率等指标。

• 定期备份 Redo Log (归档): 定期备份 Redo Log 可用于审计和数据恢复。

• 结合其他日志类型: Redo Log 专注于数据持久性，MySQL 还有其他类型的日志，共同保障数据库的可靠性。理解各种日志类型的特点和作用。

• 金融级系统保持**innodb_flush_log_at_trx_commit=1**，电商等高并发场景可适当放宽至2以提升吞吐量。

Redo Log 是 MySQL InnoDB 存储引擎中至关重要的组件，它默默地守护着数据的持久性，是构建可靠、稳定的 MySQL 应用系统的基石。深入理解 Redo Log 的工作原理和配置调优，对于数据库管理员和开发人员都至关重要。

参考：https://relph1119.github.io/mysql-learning-notes/#/mysql ,推荐理解本文之后去看原书，原书有一定深度需前后贯穿仔细理解