DigitalOcean上PostgreSQL主节点到只读节点的数据复制延迟问题

1. 现象是否与主从复制延迟有关？ #

是的，这个现象完全和主节点到只读节点的数据复制延迟直接相关。
你在主库完成写入后，主库的事务提交仅确认自身数据持久化，但DigitalOcean托管的PostgreSQL集群默认采用异步复制机制，需要把WAL（预写日志）传输到只读节点，再由只读节点回放WAL完成数据同步。如果写入完成后立即从只读节点读取，此时WAL可能还未完成传输或回放，自然读不到新数据；添加600ms延迟后，WAL同步已完成，就能稳定读到新数据。偶尔能读到的情况，是刚好那次复制同步速度快于你的读取操作。

2. 复制所需时长是多少？ #

没有固定的复制时长，它的浮动范围受多个因素影响：

• 跨区域网络延迟：你的3个只读库分布在不同区域，跨区域网络传输本身会带来基础延迟
• 主库负载：主库繁忙时，WAL生成和发送的优先级会降低
• 事务大小：写入的事务数据量越大，WAL传输和回放的时间越长
• 只读节点负载：只读节点如果在处理大量查询，WAL回放速度会被拖慢

你遇到的约600ms是当前场景下的参考值，但该数值会随上述因素变化而波动。

3. 如何测量集群的复制延迟？ #

可以通过以下几种方式直接测量：

方式一：使用PostgreSQL内置视图查询 #

连接到主库，查询pg_stat_replication视图，该视图会显示所有只读节点的复制状态，其中关键字段可反映延迟：

• write_lag：主库发送WAL到只读节点后，只读节点未写入磁盘的时间差
• flush_lag：只读节点将WAL写入磁盘，但未开始回放的时间差
• replay_lag：只读节点已写入WAL但未回放完成的时间差
  执行命令：

SELECT usename, application_name, client_addr, write_lag, flush_lag, replay_lag FROM pg_stat_replication;

方式二：通过WAL位置+时间戳计算延迟 #

1. 在主库写入一条带当前时间戳的测试记录：

INSERT INTO test_table (sync_time) VALUES (NOW());

2. 在只读节点轮询查询这条记录，直到查到后，计算当前时间与sync_time的差值，即为本次复制的实际延迟。

也可通过LSN（日志序列号）对比同步进度：

• 主库执行：SELECT pg_current_wal_lsn();
• 只读节点执行：SELECT pg_last_wal_replay_lsn();
  两个LSN的差值可反映数据同步的进度，结合时间戳即可算出延迟。

方式三：利用DigitalOcean集群监控面板 #

DigitalOcean托管的PostgreSQL集群自带监控功能，在集群管理页面可直接查看主从复制的延迟指标，包括WAL传输延迟、回放延迟等实时数据。

内容的提问来源于stack exchange，提问作者Volodymyr Nabok