Chapter 25. 预写式日志(Write-Ahead Logging (WAL))

Table of Contents
25.1. WAL 的好处
25.2. WAL 配置
25.3. 内部

预写式日志WAL) 是一种实现事务日志的标准方法。有关它的详细描述可以在大多数(如果不是全部的话)有关事务处理的书中找到。 简而言之,WAL 的中心思想是对数据文件的修改(它们是表和索引的载体)必须是只能发生在这些修改已经记录了日志之后, 也就是说,在描述这些变化的日志记录冲刷到永久存储器之后。 如果我们遵循这个过程,那么我们就不需要在每次事务提交的时候都把数据页冲刷到磁盘,因为我们知道在出现崩溃的情况下, 我们可以用日志来恢复数据库:任何尚未附加到数据页的记录都将先从日志记录中重做(这叫向前滚动恢复,也叫做 REDO)。

25.1. WAL 的好处

使用 WAL 的第一个主要的好处就是显著地减少了磁盘写的次数。 因为在日志提交的时候只有日志文件需要冲刷到磁盘;而不是事务修改的所有数据文件。 在多用户环境里,许多事务的提交可以用日志文件的一次 fsync() 来完成。而且,日志文件是顺序写的, 因此同步日志的开销要远比同步数据页的开销要小。 这一点对于许多小事务修改数据存储的许多不同的位置更是如此。

另外一个好处就是数据页的完整性。实际情况是,在 WAL 之前,PostgreSQL 从来不能保证在崩溃的情况下数据页的完整性。 在 WAL 之前,在写的过程中的任何崩溃都可能导致:

  1. 索引记录指向一个不存在的表的行

  2. 索引记录在分裂操作中丢失

  3. 完全崩溃了的表和索引页的内容,因为数据页只写了一部分

索引的问题(问题 1 和 2)可能已经通过额外的 fsync 调用修补好了,但是如果没有 WAL,那么没有很明显的处理第三种情况的方法; WAL 在日志里保存整个数据页的内容 -- 如果那些内容在崩溃后的恢复中需要确保数据页的完整性的话。

最后,WAL 还提供了数据库在线备份和恢复(backup and restore (BAR))的可能, 就像 Section 22.3 里描述的那样。 通过归档的 WAL 文件,我们可以支持恢复到手头的 WAL 文件包含的任意时刻: 我们只需要简单地安装以前的数据库的物理备份,然后重放 WAL 到自己希望的时间。 另外,物理备份还不必是数据库状态的一个即时快照 — 如果它是花了一段时间制作的话, 因为 WAL 日志的重放将修复任何内部的不一致。