469 字
2 分钟
InnoDB Redo Log 如何保证崩溃恢复
Redo Log 是 InnoDB 的重做日志,记录数据页发生的修改,用于崩溃恢复。更新数据时,InnoDB 通常先在 Buffer Pool 中修改页,并生成 redo 记录;脏页可以稍后批量写回数据文件。事务提交时要求相关 redo 达到配置定义的持久化条件,这就是 Write-Ahead Logging(WAL)的核心:数据页落盘前,描述修改的日志先持久化。
Redo Log 采用循环使用的日志空间。后台线程把脏页写回表空间后,checkpoint 向前推进,表示更早的日志不再是恢复所必需,可以被复用。若脏页刷新跟不上,checkpoint 推进受阻,日志空间压力会增加;过大的长事务也可能造成恢复和回滚成本上升。Redo Log 保存的是引擎恢复需要的信息,不是供用户按 SQL 阅读的完整变更历史。
innodb_flush_log_at_trx_commit 的常见取值:1 表示每次提交将 redo 写入并刷新到稳定存储(具体仍依赖 OS/设备兑现);2 表示每次提交写到 OS 缓存,约每秒刷新;0 表示写入和刷新通常按周期进行。后两者在操作系统崩溃或断电时可能丢失最近提交。周期并非严格实时保证。
追问
- Redo Log 与数据文件有什么关系? 日志先记录页修改,崩溃后重放未反映到数据文件的已提交修改;数据文件仍是最终表数据的持久化载体。
- checkpoint 是事务提交点吗? 不是。它表示脏页刷盘进度和可复用日志边界;提交与 checkpoint 是不同概念。
- 为什么不每次更新都同步写数据页? 随机写数据页代价高,redo 顺序写入后可由后台合并刷新脏页,提高吞吐。
InnoDB Redo Log 如何保证崩溃恢复
https://blog.xqcherry.top/posts/interview/mysql/redo-log/ 目录