2024年9月26日: PostgreSQL 17 发布!
支持的版本:当前 (17) / 16 / 15 / 14 / 13 / 12
开发版本:开发版
不受支持的版本:11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 9.1 / 9.0 / 8.4 / 8.3 / 8.2 / 8.1

28.3. 预写日志 (WAL) #

预写日志 (WAL) 是一种确保数据完整性的标准方法。大多数(如果不是全部)关于事务处理的书籍中都可以找到详细的描述。简而言之,WAL的核心概念是,只有在将更改记录到日志之后,才能将对数据文件(表和索引所在的存储位置)的更改写入数据文件,即在描述这些更改的 WAL 记录刷新到永久存储之后。如果我们遵循此过程,则无需在每次事务提交时都将数据页刷新到磁盘,因为我们知道在发生崩溃的情况下,我们可以使用日志恢复数据库:任何尚未应用于数据页的更改都可以从 WAL 记录中重做。(这是正向恢复,也称为 REDO。)

提示

因为WAL在崩溃后恢复数据库文件内容,所以对于数据文件或 WAL 文件的可靠存储,不需要日志文件系统。事实上,日志记录开销可能会降低性能,尤其是在日志记录导致文件系统数据刷新到磁盘时。幸运的是,通常可以使用文件系统挂载选项禁用日志记录期间的数据刷新,例如,在 Linux ext3 文件系统上使用data=writeback。日志文件系统确实可以提高崩溃后的启动速度。

使用WAL会导致磁盘写入次数显着减少,因为只需要将 WAL 文件刷新到磁盘即可保证事务已提交,而不是将事务更改的每个数据文件都刷新到磁盘。WAL 文件是顺序写入的,因此同步 WAL 的成本远低于刷新数据页的成本。对于处理许多触及数据存储不同部分的小型事务的服务器,尤其如此。此外,当服务器正在处理许多小型并发事务时,一个fsync WAL 文件可能足以提交许多事务。

WAL还可以支持在线备份和时间点恢复,如第 25.3 节所述。通过归档 WAL 数据,我们可以支持恢复到可用 WAL 数据覆盖的任何时间点:我们只需安装数据库的早期物理备份,然后重放 WAL 直到所需的时间。此外,物理备份不必是数据库状态的瞬时快照——如果它是在一段时间内创建的,那么重放该期间的 WAL 将修复任何内部不一致。

提交更正

如果您在文档中看到任何不正确的内容,与您对特定功能的体验不符,或者需要进一步澄清,请使用此表单报告文档问题。