深入解析MySQL日志模块 - Redo Log（重做日志）

上一篇深入解析了Binlog，本文将深入解析MySQL Redo Log。

---

前言

崩溃瞬间的时光胶囊——揭秘MySQL的"不死鸟"重生术

凌晨两点，购物节的秒杀刚刚结束，你的数据库突然遭遇断电。 当所有人以为数万笔订单将灰飞烟灭时，系统却在重启后毫发无损地复原了所有交易，这就是我们今天要说的Redo Log的能力。

在数据库系统的核心设计中，事务的持久性始终是数据安全的关键挑战。MySQL通过InnoDB存储引擎的 Redo Log 机制，实现了事务提交后的数据持久化保障。这一设计不仅是ACID特性的重要支柱，更是数据库崩溃恢复的核心基础设施。 通过理解Redo Log的底层逻辑，开发者能够更高效地进行参数调优（如innodb_log_file_size的黄金分割点计算），精准诊断日志相关的性能瓶颈（如Checkpoint滞后引发的写入抖动），并掌握高并发场景下的稳定性保障策略。

---

一、Redo Log设计原理

1.1 预写式日志的运作机制

预写式日志的核心原则是：任何数据页的修改必须优先记录日志，而后才能写入磁盘。这种设计带来三大核心优势：

1. 崩溃恢复能力：
   • 内存中的脏页可能因崩溃丢失，但Redo Log已持久化。
   • 重启时通过Redo阶段重放日志，确保数据完整性。
2. 写入性能优化：
   • 将随机I/O转化为顺序I/O（这和Binlog日志写入方式一样）
   • 允许脏页延迟刷盘，合并多次修改。
3. 事务原子性：
   • 日志记录包含Undo信息，支持事务回滚。

1.2 日志物理结构解析

Redo Log采用环形缓冲区设计，由两个固定大小的日志文件（ib_logfile0、ib_logfile1）组成循环写入空间。这和Binlog不同，Binlog是直接追加的持续增长文件（mysql-bin.000001等）。

关键组件

Log Buffer：内存缓冲区（默认16MB），暂存未刷盘的日志记录。

Log Files：磁盘日志文件组，以环形队列方式复用。

LSN：全局递增的日志序列号，唯一标识日志位置。

Checkpoint：最后成功刷盘的数据页对应的LSN位置，标记可回收的日志空间。

write pos：写入位置指针。

二、Redo Log的写入与恢复流程

2.1、Redo Log写入流程（事务提交场景）

步骤：

1. 数据修改阶段
   • 事务在Buffer Pool中修改数据页（产生脏页）。
   • 生成对应的Redo Log记录（包含：空间ID、页号、偏移量、修改内容）。
   • 记录被写入内存中的Log Buffer（默认16MB）。
2. 日志刷盘决策
   • 根据innodb_flush_log_at_trx_commit参数选择策略：
     • 0：每秒由后台线程刷盘（可能丢失1秒数据）。
     • 1：事务提交时强制刷盘（默认ACID保障）。
     • 2：写入操作系统缓存，依赖系统刷盘（折中方案）。
3. 日志文件写入
   • 日志记录被写入磁盘的ib_logfile文件组。
   • 采用顺序追加写入模式（环形缓冲区复用）。

2.2、Redo Log恢复流程（崩溃恢复场景）

步骤：

1. 前滚（Redo）阶段
   • 从最后一次Checkpoint对应的LSN开始扫描。
   • 按顺序重放所有未应用的Redo日志记录。
   • 将物理修改重新应用到数据页（无论事务是否提交）。
2. 回滚（Undo）阶段
   • 扫描Undo Log段。
   • 对所有处于ACTIVE状态的事务执行回滚。
   • 通过Undo Log中的逆向操作恢复数据。
3. Checkpoint更新
   • 将最新的持久化状态写入日志头。
   • 释放已处理的日志空间。

2.3、流程中的关键控制点

1. LSN（日志序列号）协调机制
   • 每个数据页头部存储FIL_PAGE_LSN字段。
   • 恢复时跳过LSN小于页面当前LSN的日志（避免重复应用）。
2. Checkpoint推进策略
   • 异步线程定期将脏页刷盘。
   • 满足以下条件时推进Checkpoint：
     • 日志缓冲池（Redo Log Buffer）写满。
     • ‌缓冲池脏页比例超限超过阈值（innodb_max_dirty_pages_pct），默认比例为75%。
     • 手动触发：FLUSH TABLES WITH READ LOCK 或 SET GLOBAL innodb_fast_shutdown=0。
     • 事务提交后异步触发。

三、Redo Log与Binlog的协同机制

两阶段提交（2PC）协议 原理描述：

1. InnoDB redo log 写盘，InnoDB 事务进入 prepare 状态。
2. 如果前面 prepare 成功，binlog 写盘，那么再继续将事务日志持久化到 binlog，如果持久化成功，那么 InnoDB 事务则进入 commit 状态(在 redo log 里面写一个 commit 记录)。

注意: 每个事务 Binlog 的末尾，会记录一个 XID event，标志着事务是否提交成功，也就是说，恢复过程中，Binlog 最后一个 XID event 之后的内容都应该被清除。

四、生产环境调优实践

4.1 参数配置黄金法则

日志容量计算

推荐日志总大小 = 每小时写入量 × 2
（通过SHOW STATUS LIKE 'Innodb_os_log_written'监控）

关键参数配置

innodb_log_file_size = 4G # 单个日志文件大小

innodb_log_files_in_group = 2 # 日志文件数量

innodb_flush_log_at_trx_commit = 1 # 事务提交时刷盘（保证ACID）

sync_binlog = 1 # Binlog同步刷盘

4.2 常见问题诊断

事务提交延迟高：Redo Log文件过小，频繁触发Checkpoint，增大innodb_log_file_size。

Binlog与Redo Log不一致： 两阶段提交过程中崩溃，使用mysqlbinlog工具进行数据修复。

日志写满警告： 长时间未推进Checkpoint，优化慢查询，加速脏页刷盘。

---

总结

Redo Log作为InnoDB的核心组件，通过WAL机制和精巧的日志管理，在性能与可靠性之间实现了完美平衡。MySQL 8.0版本引入原子DDL、并行日志写入等新特性，Redo Log的架构仍在持续演进......