第 25 章 预写式日志（WAL）
预写式日志（WAL）是事务日志记录的标准方法。大多数（即使不是全部）事务处理书籍中都能找到详细描述。简而言之，WAL 的核心思想是，对数据文件（即表和索引所在之处）的更改，必须在这些更改被记入日志之后才能写出；也就是说，必须在描述这些更改的日志记录被刷入永久存储之后，再去写数据文件。如果遵循这个过程，就无需在每次事务提交时都把数据页刷盘，因为我们知道，一旦发生崩溃，就可以利用日志恢复数据库：任何尚未应用到数据页上的更改，都可以根据日志记录重做。（这就是前滚恢复，也称 REDO。）
25.1. WAL 的优势 #
使用 WAL 的第一个主要优势是显著减少磁盘写入次数，因为在事务提交时只需把日志文件刷入磁盘，而不必刷写该事务更改过的每个数据文件。在多用户环境中，许多事务的提交可以通过对日志文件的一次 fsync 完成。此外，日志文件是顺序写入的，因此同步日志的代价远低于刷写数据页。对于处理大量小事务、且这些事务触及数据存储不同部分的服务器，这一点尤其明显。
下一个优势是数据页的一致性。事实是，在 WAL 出现之前，PostgreSQL 从未能保证崩溃情况下的一致性。在 WAL 之前，写入期间的任何崩溃都可能导致：
- 索引行指向不存在的表行
- 索引行在分裂操作中丢失
- 由于数据页部分写入，表或索引页内容完全损坏
索引问题（问题 1 和 2）也许可以通过额外的 fsync 调用来修复，但如果没有
WAL，如何处理最后一种情况并不明显。必要时，WAL 会把整个数据页内容保存到日志中，以确保崩溃后恢复的页面一致性。
最后，WAL 使在线备份和时间点恢复成为可能，如第 22.3 节所述。通过归档 WAL 数据，我们就能支持回退到可用 WAL 数据覆盖范围内的任意时刻：只需先安装数据库的一个较早物理备份，然后把 WAL 重放到目标时刻即可。更进一步说，这个物理备份不必是数据库状态的瞬时快照 — 即使备份是在一段时间内完成的，重放这段时间内的 WAL 也能修复任何内部不一致。