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 自定义查询中。
