“ARIES 在 预写日志 和 steal/no force 缓冲管理 上运行。更新日志通常含 LSN、事务 ID、、页 ID、redo/undo 信息;每个数据页记录 。重启按三阶段执行。”
形式陈述 ​
预写日志为每条日志记录分配单调递增的日志序列号 LSN,并区分易失缓冲区与稳定存储。为把 数据库事务 扩展到可重启的 崩溃故障 模型,WAL 规定两条不同的先行关系。
第一条约束数据页:若内存页
因此未提交脏页可以提前落盘,但恢复所需的 before-image 或逻辑 undo 信息已经安全存在。
第二条约束提交确认:在向客户端报告事务提交成功前,必须把该事务的 commit 记录以及此前的日志前缀刷到稳定日志。它不要求事务修改的每个数据页同时落盘;这些页可在崩溃后由 redo 恢复。把“page-before-log 禁止”和“commit-record 必须持久化”揉成一条,会误判哪些页允许延迟写回。
日志按前缀刷盘意味着一次顺序写可以同时覆盖多个事务的 commit,形成 group commit。共享 I/O 不改变每个事务的承诺点:只有包含其 commit LSN 的前缀稳定后,系统才可确认该事务。缓存中的日志记录数量不能替代 flushedLSN 证据。
直觉
日志像数据页修改的可追溯收据。仓库可以先把货物搬到货架,但收据必须先入保险柜;否则断电后只看见变化,却不知道它属于已提交交易还是应撤销的半次尝试。对客户说“交易完成”前,盖有 commit 章的收据也必须进保险柜。
WAL 规定顺序,不规定完整恢复算法。日志中记录物理 before/after image、逻辑操作还是混合信息,恢复从哪里开始、怎样避免重复执行,都需要进一步协议。
页写与日志写是两条独立流水线,LSN 把它们接成可检查的不等式。这个接口让缓冲管理器无需理解事务业务,也让日志管理器无需决定哪一页最适合换出;双方只在 pageLSN 与 flushedLSN 上协调。
例子与边界
页
LSN 40: T, P, before=7, after=9
LSN 50: T, COMMIT
内存页更新为 pageLSN=40。若缓冲管理器在 commit 前写回
这两个故障点展示不同责任。只满足第一条便确认 commit,可能在日志 50 丢失后把已回复客户的事务当成 loser;只满足第二条却允许 page 40 先于日志 40 落盘,则中止事务的脏页没有可靠撤销依据。
WAL 默认稳定日志本身按声明方式写入。扇区撕裂、控制器谎报 flush、日志介质永久损坏或主机与存储的缓存语义不一致,都需要校验、冗余和真实持久化屏障。它也不处理媒体恢复所需的备份基线。
逻辑日志若只写“余额减 2”,redo 前还要证明操作在恢复上下文中可重复或有页面版本条件;物理 after-image 更直接,却可能日志量大。WAL 对两者都适用,但不能从“先写日志”推导记录内容足以 undo/redo。
推论与应用
steal/no-force 缓冲管理正利用两条规则:steal 依靠已预写的 undo 信息,no-force 依靠已持久化的 redo 与 commit 证据。ARIES 恢复算法在此基础上加入 LSN 链、脏页表、重复历史和补偿日志。
与 WAL 相对,影子分页恢复通过写时复制和根指针切换保留旧页,不以逐更新日志为主要恢复依据。两者都要证明稳定写入顺序,不能把“无 WAL”误写成“无需持久化协议”。
运维验证应在 page flush 前、commit log flush 前后和回复客户端前后注入崩溃。只在空闲时优雅重启不会覆盖关键窗口;正确结果分别应表现为撤销 loser、重做 winner,且绝不能遗忘已经确认的 commit。
参考资料
- C. Mohan et al., “ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging,” ACM Transactions on Database Systems 17(1), 1992, pp. 94–162。
- Theo Härder and Andreas Reuter, “Principles of Transaction-Oriented Database Recovery,” ACM Computing Surveys 15(4), 1983, pp. 287–317。
- Jim Gray and Andreas Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann, 1992, Chs. 9–11。