目录标题
- 1. 查看主备状态
- 计算方式：
- 实际情况：
- 举个例子：
- 2. 查看历史状态
- 3. 分析日志文件
- 4. 查看数据库层面的复制状态
- 5. 检查活动事务
- 6. 检查系统资源
- 7. 检查网络状况
- 8. 检查复制槽状态
- 9. 检查未提交的两阶段事务
要排查 PostgreSQL 备库的延迟问题，您可以按照以下步骤进行：
1. 查看主备状态
-
使用
patronictl list命令：该命令会显示集群中各节点的角色、状态、时间线等信息。patronictl list该命令的输出将包括每个节点的角色、状态、时间线等信息，帮助您了解主备节点的当前状态。
patronictl list 是 Patroni 提供的命令，用于显示当前 Patroni 集群的状态和信息。在输出结果中，Lag in MB 表示每个备库（replica）与主库（primary）之间的延迟，单位是 MB（兆字节）。
计算方式：
Lag in MB 通常是基于以下因素来计算的：
-
WAL日志传输延迟：Patroni 使用 PostgreSQL 的流复制（streaming replication）机制，将主库上的 WAL（Write Ahead Log）日志传输到备库。在备库接收到 WAL 日志后，它会应用这些日志，保持与主库的同步。
-
日志差异：
Lag in MB主要通过计算主库和备库之间的 WAL 日志差异来得出。这个差异通常由以下几个指标决定：- 主库的当前 WAL LSN（Log Sequence Number）。
- 备库已接收到的最新 WAL LSN。
备库的
Lag in MB计算公式通常如下：
\[\text{Lag in MB} = \frac{\text{Current WAL LSN} - \text{Replica WAL LSN}}{1024 \times 1024}\]
这里，Current WAL LSN 是主库当前的 WAL 位置（LSN），Replica WAL LSN 是备库上已应用的最新 WAL 位置。通过计算这两个 LSN 之间的差距，并将其转换为 MB，得出备库的延迟。
- 日志传输和应用时间：
- 传输延迟：从主库到备库的 WAL 日志传输时间。
- 应用延迟：备库将接收到的 WAL 日志应用到数据库的时间。
实际情况：
Lag in MB 是一个近似值，表示备库的延迟量。它并不直接反映实际的数据延迟（即查询的响应时间），而是表示备库与主库之间的 WAL 日志差异。较大的延迟可能意味着备库未及时接收到或应用主库的 WAL 日志。
在实践中，Lag in MB 可以用于：
- 监控备库同步的健康状况。
- 发现复制延迟过大的情况。
- 调整性能优化策略，避免备库滞后过长时间。
举个例子：
假设主库的 WAL LSN 是 0/10000000，而备库的 WAL LSN 是 0/08000000。那么它们之间的差异是 0/10000000 - 0/08000000 = 0/08000000。如果每个 WAL 页的大小是 8KB，那么可以计算出这个差异对应的延迟是：
\[
\text{Lag in MB} = \frac{(0/08000000)}{1024 \times 1024} = \text{具体的 MB 数值}
\]
这个值会以 Lag in MB 显示出来，通常在 Patroni 集群的状态监控中查看。
SELECT now(),application_name,pg_current_wal_lsn() AS current_wal_lsn,sent_lsn,pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn)/1024/1024 AS lag_in_MB
FROM pg_stat_replication;
2. 查看历史状态
-
使用
patronictl history命令：该命令可以帮助您了解集群状态的变化历史，识别可能导致延迟的事件。patronictl history通过查看历史状态，您可以识别出集群状态变化的时间点，帮助定位可能导致延迟的事件。
3. 分析日志文件
-
检查主/备节点的 PostgreSQL 日志文件：日志文件通常位于 PostgreSQL 数据目录下的
pg_log目录中。cd /pg_log在该目录下，您可以找到以日期命名的日志文件，如
postgresql-<日期>.log和postgresql-<日期>.csv。
archive_command 和 restore_command 等由PG调用的外部二进制的输出打在 .log 里面
-
查找与复制相关的错误或警告信息：关注日志中是否有网络连接问题、磁盘空间不足等错误或警告信息。
grep -i 'replication' postgresql-*.csv该命令将搜索所有日志文件中包含“replication”字样的行，帮助您快速定位与复制相关的问题。
4. 查看数据库层面的复制状态
-
在主库上，执行以下 SQL 查询，查看复制状态：
SELECT * FROM pg_stat_replication;
SELECT (case pg_is_in_recovery() when 't' then null else pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn)::float end)/1024/1024 AS pg_location_diff_MB FROM pg_stat_replication;
该查询会返回当前复制连接的状态信息，包括复制延迟等。
-
在备库上，执行以下 SQL 查询，查看复制状态：
SELECT * FROM pg_stat_wal_receiver;该查询会返回备库接收 WAL 的状态信息，包括接收延迟等。
5. 检查活动事务
-
在主库上，执行以下 SQL 查询，查看当前活动事务：
SELECT * FROM pg_stat_activity WHERE state = 'active';长时间运行的活动事务可能会干扰 WAL 复制过程，从而增加复制延迟。
-
流复制
-
pg_stat_replication
6. 检查系统资源
-
检查主备节点的 CPU、内存和磁盘 I/O 使用情况：
使用系统监控工具，如
top、htop、iostat等，查看系统资源的使用情况。top该命令将显示系统的实时资源使用情况，帮助您识别是否存在资源瓶颈。
-
top
-
htop
-
iostat
7. 检查网络状况
-
确保主备节点之间的网络连接稳定，带宽充足：
使用网络监控工具，如
ping、traceroute等，检查网络延迟和丢包情况。ping <备库IP地址>该命令将测试主库与备库之间的网络连接质量，帮助您识别网络问题。
8. 检查复制槽状态
-
查看复制槽的状态：
SELECT slot_name, slot_type, database, active, active_pid FROM pg_replication_slots;如果
active列为false，说明复制槽未激活，可能导致 WAL 日志堆积。
9. 检查未提交的两阶段事务
-
查看未提交的两阶段事务：
SELECT gid, prepared, owner, database, transaction AS xmin FROM pg_prepared_xacts ORDER BY age(transaction) DESC;未提交的两阶段事务会导致 WAL 日志无法清理，增加复制延迟。
通过以上步骤，您可以全面排查 PostgreSQL 备库的延迟问题，找出可能的原因并采取相应的措施进行解决。
参考链接：
- PostgreSQL如何监控备库延迟_psql从库查看同步延迟
- PostgreSQL数据库WAL日志空间大小以及不清理的原因深入分析
- 主备同步存在多长时间的延迟_云数据库RDS
- PostgreSQL流复制三（延迟备库）
- 主从之间延迟过大如何优化？
- PostgreSQL数据库参数优化建议
- PostgreSQL 检查主从延迟mysql 查看主从延迟
- 两阶段提交
