PostgreSQL如何监控备库延迟

原创已于 2024-05-23 17:02:24 修改 · 735 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#pg 延迟监控方法 #replay_lag #write_lag #flush_lag

于 2024-05-23 16:31:47 首次发布

方案1：

主库查询

SELECT * FROM pg_stat_replication;

NOTE1：PostgreSQL 10及以后版本 pg_stat_replication视图增加了write_lag，flush_lag，replay_lag。分别表示从库wal日志写入(写入到操作系统缓存)延迟，从库wal日志刷新延迟(wal日志刷入磁盘)，从库wal日志应用延迟。

NOTE2：如果从库跟主库复制已经出现问题，比如备库需要的wal日志在主库已经被删除，则主库中该表为空
2024-05-23 14:13:56.375 CST [22978] FATAL: could not receive data from WAL stream: ERROR: requested WAL segment 0000000200000141000000C8 has already been removed

方案2：

从库查询

NOTE1：postgres_exporter 0.14 及 0.15 版本的备库延迟监控策略

NOTE2：主库宕机，或者主备wal日志同步异常时，pg_last_wal_receive_lsn () = pg_last_wal_replay_lsn () 则在从库查询也会显示无延迟。

NOTE3：pg_last_xact_replay_timestamp 函数显示备库最近WAL日志应用时间，通过与当前时间比较可粗略计算主备库延时，这种方式的优点是即使主库宕机，也可以大概判断主备延时。缺点是如果主库上只有读操作，主库不会发送WAL日志流到备库，pg_last_xact_replay_timestamp函数返回的结果就是一个静态的时间，这个公式的判断结果就不严谨了

SELECT
	CASE
		WHEN NOT pg_is_in_recovery() THEN 0
                WHEN pg_last_wal_receive_lsn () = pg_last_wal_replay_lsn () THEN 0
		ELSE GREATEST (0, EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp())))
	END AS lag,
	CASE
		WHEN pg_is_in_recovery() THEN 1
		ELSE 0
	END as is_replica;