↑↓ 选择 ↵ 打开 ⌫ 改范围 完整检索页

pgsql.cc 提供对 postgresql.org 官网内容的中文翻译,由 Pigsty 团队维护。

受支持版本: 当前版本 (18) / 17 / 16 / 15 / 14
测试与开发版本: 19 / devel
不受支持的版本: 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 / 8.0 / 7.4 / 7.3 / 7.2 / 7.1
历史版本PostgreSQL 7.4 已于 2010 年 10 月结束社区维护,本页译文保留供仍在使用旧版本的读者参考。新系统请看当前版本。

第 25 章 预写式日志(WAL)

预写式日志(WAL) 是一种标准的事务日志方法。它的详细 描述可以在大多数(即使不是全部)关于 事务处理的书中找到。简言之,WAL 的 核心概念是:对数据文件(表和索引 所在之处)的更改必须只在这些更改已被记录 之后写入,也就是在日志记录已刷写到 永久存储之后。如果遵循这一过程,就不需要在每次 事务提交时把数据页刷写到磁盘,因为我们 知道一旦发生崩溃,可以用日志恢复 数据库:尚未应用到 数据页的任何更改将先从日志记录中重做(这是 前滚恢复,也称 REDO),然后由 未提交事务所做的更改将从数据页中 移除(后滚恢复,UNDO)。

25.1. WAL 的优势 #

使用 WAL 的第一个明显好处是 大幅减少磁盘写入次数,因为在事务 提交时只需要把日志文件刷写到磁盘; 在多用户环境中,许多事务的提交 可以通过对日志文件的一次 fsync() 完成。此外,日志文件是 顺序写入的,因此同步日志的代价远小于 刷写数据页的代价。

下一个好处是数据页的一致性。事实是, 在 WAL 之前, PostgreSQL 从不能保证 崩溃后的一致性。在 WAL 之前,写入期间的任何崩溃都可能导致:

  1. 索引行指向不存在的表行
  2. 索引行在分裂操作中丢失
  3. 由于数据页部分写入,表或索引页内容完全损坏

索引的问题(问题 1 和 2)或许可以通过额外的 fsync() 调用修复,但如果没有 WAL,如何处理最后一种情况并不 明显;WAL 在需要时会把整个数据 页内容保存在日志中,以确保崩溃后恢复的页面 一致性。

提交更正

译文有误、术语不当或页面显示问题,请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题,请在当前版本的对应页面向上游反馈;上游不再修订已结束维护的版本。