【存储工程】WAL 与崩溃恢复：ARIES 协议
内容提要
本文介绍数据库崩溃恢复的核心协议ARIES，包括WAL三条规则、日志记录格式、三阶段恢复流程（分析、重做、撤销），并以MySQL InnoDB为例分析工业实现，最后讨论WAL写放大问题及优化手段，如组提交、日志压缩和并行恢复。
延伸解读
ARIES 的工程取舍：Steal + No-Force 的代价
ARIES 选择 Steal + No-Force 组合，允许未提交事务的脏页刷盘，且提交时只刷日志，从而获得高性能。但这要求恢复时同时支持 Redo 和 Undo，逻辑最复杂。相比之下，Force 或 No-Steal 策略虽简化恢复，却牺牲了性能或内存灵活性。理解这一权衡，有助于解释为何现代数据库普遍采用 ARIES 式设计。
CLR 机制：崩溃恢复的幂等性保障
补偿日志记录（CLR）是 ARIES 的精妙设计。每次撤销操作都会写入 CLR，其 UndoNextLSN 字段指向下一条待撤销记录，使得恢复过程可断点续作。即使回滚中再次崩溃，也能跳过已撤销部分，保证幂等性。这一机制避免了重复撤销，是 ARIES 在多次崩溃下仍能正确恢复的关键。
InnoDB 与 ARIES 的差异：Undo 独立存储
InnoDB 虽基于 ARIES，但将 Undo Log 存放在独立表空间，而非 WAL 中，且 Undo 页修改也产生 Redo。恢复时 Redo 完成后可先对外服务，Undo 在后台异步执行。这与 PostgreSQL 仅靠 REDO 和 CLOG 处理未提交事务不同。理解这些差异，有助于避免用 ARIES 伪代码生搬硬套工业实现。
WAL 写放大：性能与持久性的平衡
WAL 引入额外写入，一次小更新可能产生约 33KB 磁盘写入（含 Redo、Undo、数据页和双写缓冲），写放大达 330 倍。但实际摊销远低，因页面刷盘可合并。组提交、日志压缩、并行恢复等优化可缓解开销。理解写放大来源，有助于在配置数据库时权衡持久性与性能。
Q&A
什么是ARIES协议？它主要解决什么问题？
ARIES（Algorithm for Recovery and Isolation Exploiting Semantics）是IBM研究院在1992年提出的数据库崩溃恢复协议。它主要解决数据库系统在崩溃后如何恢复到一致状态的问题，确保已提交事务的修改持久化，未提交事务的修改被撤销。ARIES采用Steal + No-Force策略，通过WAL、LSN、检查点、CLR等机制实现崩溃恢复。
WAL的三条规则是什么？
WAL的三条规则是：1. 预写规则（Write-Ahead Rule）：在将修改后的数据页写入磁盘之前，必须先将对应的日志记录写入持久化存储。2. 重做规则（Redo Rule）：事务提交时，其所有日志记录必须已经写入持久化存储。3. 撤销规则（Undo Rule）：如果允许未提交事务的脏页刷入磁盘（Steal策略），日志中必须包含足够的信息来撤销这些修改。
ARIES的崩溃恢复分为哪三个阶段？每个阶段的主要任务是什么？
ARIES的崩溃恢复分为三个阶段：1. 分析阶段（Analysis）：从检查点开始正向扫描日志，重建脏页表（DPT）和活动事务表（ATT），确定Redo阶段的起始点。2. 重做阶段（Redo）：从DPT中最小的recLSN开始，正向扫描日志，重做所有需要重做的修改，包括未提交事务的修改，将数据库恢复到崩溃前一刻的状态。3. 撤销阶段（Undo）：从ATT中未提交事务的LastLSN开始，反向扫描日志，撤销所有未提交事务的修改，并写入CLR记录以保证幂等性。
什么是LSN？它在WAL和崩溃恢复中有什么作用？
LSN（Log Sequence Number）是日志序列号，每条日志记录都有一个唯一的、单调递增的LSN。在WAL和崩溃恢复中，LSN用于：1. 数据页头部的page_lsn记录最后一次修改该页面的日志LSN，用于Redo阶段判断是否需要重做。2. 日志记录中的prev_lsn指向同一事务的上一条日志，用于Undo阶段沿事务链回滚。3. 全局的flushed_lsn记录已刷入磁盘的日志最大LSN，用于判断数据页是否可以安全刷盘。4. 检查点中的checkpoint_lsn用于Analysis阶段确定扫描起点。
什么是补偿日志记录（CLR）？它有什么作用？
补偿日志记录（Compensation Log Record，CLR）是ARIES中用于记录撤销操作的特殊日志记录。当系统执行Undo操作时，每撤销一条日志记录，就会写入一条CLR。CLR包含UndoNextLSN字段，指向下一条需要被撤销的日志记录。它的作用是：1. 保证撤销操作的幂等性，即使回滚过程中再次崩溃，恢复程序也能通过UndoNextLSN跳过已撤销的记录，从断点继续。2. CLR自身永远不需要被撤销。
InnoDB如何解决撕裂页（Torn Page）问题？
InnoDB通过双写缓冲区（Doublewrite Buffer）解决撕裂页问题。具体机制是：在将脏页写入数据文件之前，先将页面的完整副本写入系统表空间中的连续区域（Doublewrite Buffer），并执行fsync。然后再将页面写入实际位置。恢复时，如果发现页面校验和不正确（即撕裂），则从Doublewrite Buffer中读取完整副本覆盖损坏页面，然后继续正常的Redo恢复。
什么是WAL写放大？有哪些优化手段？
WAL写放大是指由于WAL机制，实际写入磁盘的数据量远大于用户修改的数据量。例如，一次UPDATE操作可能需要写入Redo Log、Undo Log、数据页和Doublewrite副本，导致写放大倍数可能高达330倍。优化手段包括：1. 组提交（Group Commit）：将多个事务的日志合并为一次fsync，减少fsync次数。2. 日志压缩：对日志记录进行压缩，或合并对同一页面的多次修改。3. 并行恢复：使用多线程并行应用Redo日志，加快恢复速度。
InnoDB的Redo Log和Undo Log分别对应ARIES的什么概念？
InnoDB的Redo Log对应ARIES的Redo日志，用于记录页面的物理修改，在崩溃后重做已提交事务的修改。Undo Log对应ARIES的Undo信息，记录事务的逻辑反操作，用于回滚未提交事务和实现MVCC。与ARIES不同的是，InnoDB的Undo Log存储在独立的Undo表空间中，而不是WAL文件中，且Undo Log的修改本身也会产生Redo Log记录。
