PostgreSQL的流复制集群在大多数时候表现稳定，但稳定不等于绝对可靠。主库写入了10万条记录，从库只回放了99999条，这种偏差可能长期潜伏，直到某天主库宕机、应用切到从库，用户才发现数据“丢”了。事后追责已经没有意义，真正有价值的做法是在故障发生前建立周期性的数据一致性校验机制。本文将从数据不一致的成因讲起，逐一分析几种可落地的校验方案。
为什么主从节点会出现数据不一致
首先要明确一点：流复制本身是基于WAL（预写式日志）的物理复制，只要复制链路正常、没有异步延迟，理论上从库就是主库的逐块拷贝。但现实中至少有三类情况会打破这个假设。
第一类是复制延迟导致的“时间窗口不一致”。异步复制模式下，主库提交事务后不等待从库确认，如果主库在从库回放完成前崩溃，未回放的WAL就永久丢失了。这不是数据损坏，但在业务视角上就是不一致。可以通过设置synchronous_commit为remote_apply来缓解，代价是写入延迟增加。
第二类是磁盘层面的静默错误。硬件RAID卡缓存问题、磁盘坏块、文件系统损坏，都可能让数据块在写入后悄然改变。这类错误不会被PostgreSQL主动发现，除非开启了数据页checksum。PostgreSQL从9.3版本开始支持在初始化数据库时启用checksum，之后每次读取数据页都会校验，一旦发现不匹配立即报错，防止坏数据扩散。
第三类是人为操作失误。比如在从库上误开了可写配置（设置了default_transaction_read_only = off并手动写入数据），或者用pg_rewind恢复时操作不当，都可能引入主库上不存在的数据。
方案一：启用并利用数据页checksum做块级校验
数据页checksum是最底层的校验机制，它对每个8KB的数据页计算校验值并存储在页头中。开启后有两种发挥作用的方式：一是被动检测，任何读取到坏页的操作都会抛出类似“page verification failed”的错误；二是主动扫描，利用pg_checksums工具对整个数据目录做全量校验。
初始化集群时开启checksum只需要在initdb时加参数：
initdb -D /pgdata/main --data-checksums
如果集群已经运行了很久不想重建，PG12之后可以通过pg_checksums --enable离线启用，PG17之后甚至支持在不停机的情况下通过pg_enable_checksums()函数在线开启。校验已有集群的命令如下：
# 必须先停止数据库实例 pg_ctl -D /pgdata/main stop # 全量校验数据页，-c 表示 check 模式 pg_checksums -D /pgdata/main -c
需要注意，pg_checksums只能检测本节点数据页是否损坏，它校验的是“这个节点自己内部的一致性”，并不能直接对比主从节点之间的差异。它的价值在于提前发现磁盘静默错误，属于一致性保障体系的第一道防线。主库和从库可以各自定期执行扫描，再结合下面的表级比对手段形成完整闭环。
缺点也比较明显：开启checksum会带来大约2%到5%的性能损耗，全量扫描对大库耗时较长，离线模式下还需要停机窗口。对于TB级数据库，建议安排在业务低峰期进行。
方案二：表级与行级数据比对工具
要真正回答“主从数据是否完全一致”，需要做表级甚至行级比对。自己写全表MD5比对脚本当然可行，但对生产大表来说既慢又影响性能，业界更常用成熟的第三方工具。
最经典的是percona toolkit中的pt-table-checksum思路衍生工具，以及PostgreSQL社区里广泛使用的pg-compare、pgdatacopy等。以一个简单的自研校验思路为例，对每张表按主键分块计算聚合哈希：
-- 按 id 分块，对业务列计算 md5 聚合，主从库各执行一次，对比结果
SELECT
(id / 10000) AS chunk_no,
count(*) AS row_cnt,
md5(string_agg(md5(t::text), '' ORDER BY id)) AS chunk_hash
FROM business_table t
WHERE id BETWEEN 1 AND 100000
GROUP BY 1
ORDER BY 1;这段SQL的逻辑是：把表按主键切成固定大小的块，每块内先把每行转成文本再算MD5，再拼起来对整块算一次MD5。主库和从库分别执行，逐块对比chunk_hash，不一致的块就是嫌疑范围，再进一步对嫌疑块做逐行比对定位差异。分块的好处是单次查询代价可控，还支持断点续跑。
比对时务必注意一个关键点：必须在从库回放追上主库后再执行快照查询，否则比对的是不同时间点的数据，会产生大量误报。可以利用pg_current_wal_lsn()在主库取LSN，然后在从库执行pg_last_wal_replay_lsn()确认已经回放到该位置，再开始采样。
方案三：复制状态监控与延迟预警
校验是事后确认，监控是事前预警，两者缺一不可。PostgreSQL提供了pg_stat_replication视图，主库上可以直接观察每个从库的复制状态：
SELECT
client_addr,
state,
sent_lsn,
replay_lsn,
(sent_lsn - replay_lsn) AS replay_lag_bytes,
replay_lag
FROM pg_stat_replication;其中replay_lag显示回放延迟时间，replay_lag_bytes（通过LSN差值计算）显示落后字节量。建议将这两个指标接入监控系统，设置分级告警：延迟超过秒级提示关注，超过分钟级触发人工介入。如果发现state字段长期不是streaming，说明复制链路已经异常，必须立即处理。
在从库侧，还可以关注pg_stat_wal_receiver视图和日志中的WAL回放错误信息。一个容易被忽略的实践是：定期对关键表执行ANALYZE并对比主从的表大小（pg_total_relation_size），如果两边表大小差异明显且持续扩大，往往是数据不一致的早期信号。
校验方案选型建议
综合来看，三种手段各有定位：数据页checksum负责发现节点内部的物理损坏，建议所有生产集群默认开启；表级哈希比对负责发现节点之间的逻辑差异，建议以周或月为周期执行，重点覆盖核心业务表；复制监控负责实时发现链路异常，是日常运维的基本功。
对于大规模集群，可以把三者的执行错开安排：监控持续运行，checksum扫描放在低峰期，表级比对则采用滚动分块的方式每天跑一部分，避免单次任务过重。校验发现不一致后，如果差异范围明确且表不大，可以基于主库数据修复从库；如果差异原因不明，最稳妥的做法是重建从库，切忌带着未确认的数据偏差执行故障切换。数据一致性这件事，永远是把问题暴露在演练环境里，好过在真实故障中付出代价。
PostgreSQL数据一致性流复制校验数据校验工具修改时间：2026-09-07 12:40:42