SQL PostgreSQL 的 pg_stat_replication_lag 的复制延迟监控

postgresql 中并没有内置的 pg_stat_replication_lag 视图或函数——这是一个常见的误解。实际用于监控复制延迟的是系统视图 pg_stat_replication，配合 WAL 位置计算得出延迟值。关键在于理解如何从该视图中准确提取主从之间的滞后（以字节或时间形式），并稳定用于告警或可视化。

核心原理：用 pg_stat_replication 计算字节级延迟

在主库上查询 pg_stat_replication，可看到每个流复制客户端（即备库）的当前同步状态。其中两个关键字段是：

• sent_lsn：主库已发送到备库的最新 WAL 位置（LSN）
• replay_lsn：备库已实际写入并回放完成的 WAL 位置

二者差值即为尚未被备库应用的 WAL 字节数：

SELECT   client_addr,   pg_wal_lsn_diff(sent_lsn, replay_lsn) AS lag_bytes FROM pg_stat_replication;

结果为正整数（单位：字节），0 表示完全同步；越大说明延迟越严重。注意：若备库未启用 hot_standby = on 或未开始回放，replay_lsn 可能为 NULL，此时需单独处理。

时间级延迟（需备库配合）

仅靠主库无法直接知道“延迟多少秒”，因为 WAL 生成速率不恒定。较可靠的方式是结合备库上的 pg_last_wal_receive_lsn() 和 pg_last_wal_replay_lsn()，再与主库的 pg_current_wal_lsn() 对比，并估算时间差：

• 主库记录当前 LSN 和时间戳（如通过 cron 定时采集）
• 备库定时上报接收/回放 LSN 及本地时间
• 用主库 WAL 生成时间 + 备库回放偏移反推延迟秒数（需 WAL 归档或逻辑解码辅助校准）

更轻量的做法是使用扩展 pg_stat_statements 配合自定义脚本，或借助 pg_replication_slots 中的 active 和 restart_lsn 判断是否卡住。

常见误判与稳定性建议

延迟值瞬时抖动属正常现象，不应直接触发告警。建议：

• 对 lag_bytes 做滑动窗口统计（如最近 5 分钟最大值 > 100MB 才告警）
• 排除网络抖动影响：检查 pg_stat_replication.sync_state 是否长期为 async 或 potential
• 确认备库磁盘 I/O 能力，replay_lsn 滞后但 received_lsn 接近 sent_lsn，说明是回放瓶颈而非传输问题
• 避免在高负载主库上频繁轮询 pg_stat_replication，可设为 10–30 秒间隔

一键监控 SQL 示例（带安全判断）

以下语句兼容 PostgreSQL 10+，自动忽略 NULL 回放位置，并标记异常状态：

SELECT   client_addr AS standby_ip,   COALESCE(pg_wal_lsn_diff(sent_lsn, replay_lsn), -1) AS lag_bytes,   CASE     WHEN replay_lsn IS NULL THEN 'not_replaying'     WHEN pg_wal_lsn_diff(sent_lsn, replay_lsn) > 100 * 1024^2 THEN 'high_lag'     ELSE 'ok'   END AS status FROM pg_stat_replication;

可将其封装为视图或集成进 prometheus 的 postgres_exporter 自定义查询中。