查看
主库查询
SELECT * FROM pg_stat_replication;
https://www.modb.pro/db/1692140474278694912
https://patroni.readthedocs.io/en/latest/patronictl.html
备库延迟的原因
PostgreSQL 备库延迟的原因可能包括以下几个方面:
- 网络问题:网络延迟或不稳定可能导致备库接收 WAL 日志的速度变慢。
- WAL 数据段缺失:如果备库所需的 WAL 数据段在主库上已经被替换或回收,可能导致复制延迟。
- 系统繁忙:主库或备库系统繁忙,导致数据复制功能受到影响,系统性能降低。
- 硬件性能不足:硬件性能不足以支持数据复制的速度,尤其是在高负载情况下。
- 错误的 PostgreSQL 参数设置:例如,
max_wal_senders
数量设置不足,可能导致复制性能问题。 - 恢复时消耗大量 CPU:例如,开启数据文件 checksum 时,会额外消耗启动进程的 CPU。
- 主库频繁的离散 IO 操作:如大量索引变更、VACUUM 操作等,可能导致备库处理延迟。
- 频繁或大量的系统调用:例如,大批量删除对象时,可能会引起复制延迟。
- 备库与主库系统时间不一致:如果系统时间不同步,延迟备库可能不会按配置的延迟来应用变更。
- 备库资源限制:例如,
shared buffer
容量不足,可能导致更多的数据文件写操作,从而引起延迟。 - IOPS 能力和 IO 延迟:使用 IOPS 能力更强、IO 延迟更低的存储设备,如 NVMe SSD,可以减少延迟。
为了监控复制状态和延迟,可以使用 pg_stat_replication
视图查询相关数据,如 state
、sent_lsn
、write_lsn
、flush_lsn
和 replay_lsn
等字段,以及 write_lag
、flush_lag
和 replay_lag
这些表示延迟的字段。此外,还可以使用函数 pg_is_in_recovery()
、pg_is_wal_replay_paused()
、pg_last_wal_receive_lsn()
、pg_last_wal_replay_lsn()
和 pg_last_xact_replay_timestamp()
来获取复制状态和延迟信息。
高可用切换
maximum_lag_on_failover: 1048576
https://developer.aliyun.com/article/775029