PostgreSQL 备库的延迟问题

要排查 PostgreSQL 备库的延迟问题，您可以按照以下步骤进行：

1. 查看主备状态

• 使用 patronictl list 命令：该命令会显示集群中各节点的角色、状态、时间线等信息。

  patronictl list
  

  该命令的输出将包括每个节点的角色、状态、时间线等信息，帮助您了解主备节点的当前状态。
  

patronictl list 是 Patroni 提供的命令，用于显示当前 Patroni 集群的状态和信息。在输出结果中，Lag in MB 表示每个备库（replica）与主库（primary）之间的延迟，单位是 MB（兆字节）。

计算方式：

Lag in MB 通常是基于以下因素来计算的：

1. WAL日志传输延迟：Patroni 使用 PostgreSQL 的流复制（streaming replication）机制，将主库上的 WAL（Write Ahead Log）日志传输到备库。在备库接收到 WAL 日志后，它会应用这些日志，保持与主库的同步。

2. 日志差异：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，得出备库的延迟。

3. 日志传输和应用时间：
   • 传输延迟：从主库到备库的 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 查看主从延迟
• 两阶段提交