在MySQL中Undo Log与Redo Log在崩溃恢复时的协作流程是怎样的-mysql教程-PHP中文网

崩溃恢复必须先redo再undo，因为需先用redo log将所有已记录的物理变更重放到数据页，确保页状态完整可逆；若先undo，未提交事务的中间修改可能已部分刷盘且未被覆盖，导致数据页处于错误中间态，破坏原子性。

在mysql中undo log与redo log在崩溃恢复时的协作流程是怎样的

崩溃恢复时为什么必须先 redo 再 undo

因为恢复的目标是让数据页回到崩溃前的“最新一致状态”，而不是直接回滚。如果先执行 undo log，未提交事务的中间修改可能已被部分刷盘，又没被重放覆盖，会导致内存页处于错误中间态——破坏原子性。只有先用 redo log 把所有已写入日志的物理变更（无论事务是否提交）全部重放到数据页上，才能确保页状态完整、可逆。

常见错误现象：人为删除或截断 ib_logfile* 后强行启动 MySQL，redo log 扫描起点错乱，导致重做阶段卡在 redo log parsing completed 之前，实例 hang 住无法完成恢复。

恢复顺序不可配置、不可跳过，由 InnoDB 启动逻辑硬编码决定
redo log 重做不依赖 undo log 是否可用；但 undo log 回滚必须基于重做后的页状态
若 undo log 段损坏（如 ibdata1 尾部坏块），恢复可能在第二阶段报 ERROR 1030 (HY000): Got error 168 from storage engine

Redo Phase 实际做了什么

这个阶段只读取并应用 redo log 中从 checkpoint LSN 开始的所有日志记录，对 Buffer Pool 中对应的数据页执行原样修改（比如把 page 123 offset 456 处的字节从 0x11 改成 0x22）。它不解析 SQL，不查事务状态，也不写磁盘——只是把日志里记的物理操作再执行一遍。

容易踩的坑：innodb_flush_log_at_trx_commit=0 或 =2 时，崩溃后会丢失部分已提交事务的 redo log 记录，这部分事务无法恢复，不是 bug，是配置明确放弃持久性保障的结果。

日志扫描起点来自 ibdata1 中存储的最后 checkpoint 位置，不是从头读整个 ib_logfile*
重做耗时主要取决于脏页数量和磁盘 I/O 性能，SSD 上通常秒级；HDD 上若待重做记录超百万条，可能持续数分钟
日志中出现大量 Applying log record 行，且紧随 Starting crash recovery from checkpoint LSN=...，说明正在重做

Undo Phase 如何识别并清理未提交事务

重做完成后，InnoDB 扫描 undo log 段，查找所有标记为 ACTIVE 的事务（即没有 TRX_UNDO_CACHED 或 TRX_UNDO_TO_FREE 状态的事务），用其记录的前镜像执行反向操作：对 INSERT 做 DELETE，对 UPDATE 做逆向 UPDATE，对 DELETE 做反向 INSERT。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

关键点在于：这个阶段只处理未提交事务，已提交事务的修改已在 Redo Phase 固化，不会被 undo 影响。

long running transaction 会阻塞 undo log 清理，导致 ibdata1 持续膨胀，甚至触发 ERROR 1114 (HY000): The table is full
可通过 SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), TRX_STARTED)) > 60 快速定位运行超 60 秒的事务
innodb_undo_tablespaces 配置启用独立 undo 表空间后，ibdata1 不再承载 undo 段，避免共享表空间无限增长

两次写（double write）如何配合 redo 恢复

redo log 只能修复“内容正确但未刷盘”的页，无法修复“写了一半就崩溃”的半页（torn page）。这时候 dblwr 文件起关键作用：InnoDB 刷脏页前，会先将完整页拷贝到 #ib_*.dblwr 文件中。崩溃重启后，MySQL 先加载这些 dblwr 页面，用它们修复损坏的数据页，再应用 redo log。

典型问题：若 innodb_doublewrite=OFF，且磁盘发生部分写失败，崩溃恢复时可能因数据页损坏而直接报错退出，无法继续。

dblwr 文件默认位于 MySQL 数据目录下，文件名形如 #ib_16384_0.dblwr
恢复过程中若发现某数据页校验失败（checksum mismatch），会尝试从 dblwr 中找对应页副本进行替换
该机制与 redo log 协同，构成崩溃恢复的底层安全边界，不可绕过

实际恢复链条非常紧凑：checkpoint LSN → 加载 dblwr → 修复损坏页 → 重放 redo → 构建完整内存页 → 扫描 undo → 回滚活跃事务。任何一环缺失或损坏，都会中断恢复流程。最常被忽略的是 dblwr 文件权限异常或磁盘空间满导致其写入失败——此时即使 redo log 完好，也无法完成页修复。