一、引言
断电对数据库而言是一场未经协商的"强制中断"——内存中的数据瞬间蒸发，正在执行的事务戛然而止。在这样的极端场景下，数据库能否保证已提交事务不丢失、未提交事务不留痕，即所谓的数据一致性（Consistency），是衡量其可靠性的核心标尺。
海山数据库凭借 WAL 预写日志、两阶段提交协议和精细的页面校验机制，构建了一套从写入到恢复的端到端一致性保障体系。
二、一致性保障的基石：WAL 协议
2.1 先写日志原则
数据库的一致性原则：数据页可以被延迟写入磁盘，但 WAL 日志必须先于数据页持久化。 这意味着，任何一次数据修改在反映到磁盘上的数据文件之前，其对应的 WAL 记录必须已经安全落盘。
这一原则的精妙之处在于：即便断电导致内存中的脏页丢失，只要 WAL 日志完好，数据库重启后就能通过"重放"（redo）WAL 记录，将那些"已提交但未刷盘"的事务重新应用到数据文件中，从而恢复到一致状态。反之，那些"未提交但已部分写入数据页"的修改，则会在恢复过程中被回滚。
2.2 事务提交与 WAL 刷写
当执行 COMMIT 时，数据库会将该事务的提交记录写入 WAL 缓冲区，并根据 synchronous_commit 参数的设置决定何时将 WAL 刷写到磁盘：
- synchronous_commit = on（默认）：COMMIT 会等待 WAL 记录真正写入磁盘后才返回成功。这是最强一致性保证——一旦客户端收到"提交成功"，该事务的数据就绝不会因断电而丢失。
- synchronous_commit = remote_write / remote_flush：用于同步复制场景，将一致性保证延伸到备库。
关键理解：一致性与持久性是两个维度。 synchronous_commit = off 牺牲的是持久性（可能丢事务），但不会牺牲一致性（不会出现脏数据或半提交状态）。
三、Full Page Writes：抵御部分写问题
3.1 部分写的威胁
操作系统和磁盘通常以页（Page）为单位管理存储，数据库的数据页默认为 8KB。断电可能发生在一次 8KB 页写入的中途，导致页面上半部分是新数据、下半部分是旧数据，即"部分写"（torn page）。这种损坏会使数据页内部的行指针、头部信息自相矛盾，严重破坏一致性。
3.2 Full Page Writes 机制
数据库通过 full_page_writes 参数应对此问题。当该参数开启时（默认开启），在每次 checkpoint 之后，对某个数据页的第一次修改会将整个页面的完整镜像写入 WAL，而不仅仅是修改的行。
恢复时，如果检测到某页的 WAL 记录包含完整页镜像，就直接用该镜像覆盖损坏页，再继续重放后续记录。这有效修复了部分写问题，代价是 WAL 日志体积增大（尤其在 checkpoint 后首次修改大量页时）。这是一个用空间换一致性的经典权衡，生产环境中务必保持开启。
3.3 页面校验和
数据页校验和（checksum）功能，在 initdb 时通过 --data-checksums 启用。每个 8KB 页都会计算一个 16 位校验和并存储在页头。读取页面时会重新计算并比对，一旦不匹配即报错并阻止读取。这是断电后检测页损坏的第一道防线，强烈建议在初始化时启用。
四、Checkpoint：一致性快照的锚点
Checkpoint 是崩溃恢复的起点。执行 checkpoint 时，数据库 将所有已修改的脏页刷写到数据文件，并在 WAL 中记录一条 checkpoint 记录，其中包含了" redo 起始位置"等关键信息。
断电重启后，数据库从控制文件（pg_control）中读取最后一次 checkpoint 的位置，从该点开始重放 WAL。这意味着：
Checkpoint 的频率是一致性与性能的平衡点。过于频繁的 checkpoint 会导致大量 I/O 并增加 full_page_writes 的写入量；过于稀疏的 checkpoint 则会延长崩溃恢复时间（需重放更多 WAL）。通过 checkpoint_timeout（默认 5 分钟）和 max_wal_size（默认 1GB）控制节奏，并在日志中监控 checkpoint 间隔与耗时。
五、崩溃恢复的一致性自证
5.1 自动恢复流程
数据库 重启时检测到上次未正常关闭，会自动进入崩溃恢复：
- 读取 pg_control，定位最近一次 checkpoint 记录。
- 从该 checkpoint 的 redo 点开始，依次重放 WAL 记录。
- 遇到事务提交记录，将对应变更应用到数据页（redo）。
- 遇到事务中止记录或检测到未提交事务的变更，执行回滚（undo，通过 WAL 中的反向操作或丢弃未完成事务）。
- 重放至 WAL 末尾，写入新的 checkpoint，恢复完成。
整个过程不需要人工干预，且能保证最终状态等价于"所有已提交事务已应用、所有未提交事务已回滚"的一致状态。
5.2 避免一致性的常见问题
实践中，有几个配置误区会削弱断电后的一致性保障：
（1）文件系统挂载未启用同步写入。 某些文件系统（如 ext4）默认开启写缓存，fsync 可能只是写入缓存而非真正落盘。应在挂载时使用 data=ordered 或 data=journal 模式，并确认存储设备未使用危险的 write-back 缓存。可通过 数据库 的 pg_test_fsync 工具验证 fsync 行为。
（2）关闭 fsync。 fsync = off 会让 数据库 跳过 WAL 的强制刷盘，在断电时可能导致数据文件与 WAL 不一致，造成不可恢复的损坏。生产环境绝对禁止关闭 fsync。
（3）忽视 WAL 归档。 虽然 WAL 归档主要用于时间点恢复（PITR），但它也在灾难性损坏时提供了"从备份重放到故障前一刻"的能力。archive_mode = on 配合 archive_command 将填满的 WAL 段复制到安全存储，是数据一致性兜底的关键一环。
六、实践配置建议
综合上述机制，以下是保障数据库断电后数据一致性的核心配置清单：
推荐值 | 作用 | |
|---|---|---|
fsync | on | 强制 WAL 落盘，一致性根本保证 |
synchronous_commit | on | 提交事务的持久性保证 |
full_page_writes | on | 防御部分写，保障页级一致性 |
wal_level | replica或更高 | 支持归档与复制 |
archive_mode | on | WAL 归档，灾难恢复兜底 |
checkpoint_timeout | 5min~15min | 平衡恢复时间与 I/O 压力 |
数据页 checksum | 初始化时启用 | 检测页损坏 |
七、结语
数据库的数据一致性并非依赖单一机制，而是由 WAL 协议、full page writes、checkpoint、页面校验和、fsync 刷盘等多层防线共同构筑的体系。断电只是一次"压力测试"——如果这些机制配置正确、运行正常，数据库就能在重启后自动恢复到一致状态；如果配置疏漏，断电就可能演变为数据灾难。理解每一层机制的作用边界，并在工程实践中严格落实配置要求，才是守护数据一致性的根本之道。
