日志位点监控

select *,
  pg_size_pretty(pg_wal_lsn_diff(WP, AP)) as "WP-AP",
  pg_size_pretty(pg_wal_lsn_diff(AP, CP)) as "AP-CP",
  pg_size_pretty(pg_wal_lsn_diff(WP, CP)) as "WP-CP",
  pg_size_pretty(pg_wal_lsn_diff(WP, redo_lsn)) as "WP-REDO"
from
  (select pg_current_wal_insert_lsn() as WP,
          polar_oldest_apply_lsn() as AP,
          polar_consistent_lsn() as CP,
          redo_lsn
   from pg_control_checkpoint()
  ) as lsn_info;

• 主节点无法重用WAL日志，导致WAL日志大量堆积，数据库集群占用的存储空间上涨。该异常可以通过监控数据库集群的存储空间或WAL日志存储空间发现。
• 由于备节点查询存在较大的延迟，导致备节点无法查询到主节点最近更新的数据。
• 如果使用了读写分离组件（Proxy），Proxy可能将所有请求都路由到主节点进行处理，无法发挥读写分离的作用。
• 导致一致性位点和checkpoint位点延迟，影响集群的可用性。

1. 执行以下命令，查询复制槽，确认主备同步是否中断。

   select * from polar_replication_slots;

   查看是否存在active为f的复制槽，如果存在，则说明该备节点与主节点的同步发生了中断，需要进一步排查主备同步中断的原因。
   说明 PolarDB根据不同的部署形态，其复制槽可能分为两类，即replica和standby。复制槽类型与PolarDB集群中的节点类型相对应，replica节点与主节点共用一份数据，主节点与replica节点的同步如果断开，对主节点的影响较大，需要及时处理。standby节点与主节点类似传统PostgreSQL的主备，各自有独立的数据。复制槽类型可以通过其名称（上述查询中的slot_name字段）进行区分。
2. 如果主备同步正常，执行以下命令，查看主备延迟情况。

   select pid, usename, application_name, client_addr, state,
          pg_wal_lsn_diff(pg_current_wal_insert_lsn(), sent_lsn) as sent_delay,
          pg_wal_lsn_diff(pg_current_wal_insert_lsn(), write_lsn) as write_delay,
          pg_wal_lsn_diff(pg_current_wal_insert_lsn(), flush_lsn) as flush_delay,
          pg_wal_lsn_diff(pg_current_wal_insert_lsn(), replay_lsn) as replay_delay
   from pg_stat_replication;

   查询结果可能存在以下四类延迟：
   • sent_delay：主节点发送日志的延迟。
   • write_delay：备节点将接收到的日志写入存储的延迟。
   • flush_delay：备节点将接收到的日志flush到存储的延迟。
   • replay_delay：备节点回放日志的延迟。
     说明 如果备节点的回放延迟（replay_delay）较大，通常需要登录备节点所在主机，查看备节点的startup进程的运行状况，视具体情况进一步排查。
   根据以上命令，查询延迟较大的备节点，进而排查对应备节点延迟较大的原因。

1. 如果同时存在备节点延迟大的情况，请优先处理备节点延迟问题，因为备节点延迟会导致一致性位点延迟。
2. 是否存在批量导入或者批量修改数据的场景，导致短时间内产生大量脏数据，此时数据库集群可能无法及时将脏页落盘，导致一致性位点延迟。此类情况属于正常的业务请求导致一致性位点延迟变大，延迟情况应该会在此类业务请求过后恢复到较小的水位。
3. 是否存在集群规格和shared_buffer较大的情况。shared_buffer越大，数据库的buffer pool越大，其能缓存的buffer越多，可能存在的脏页也越多。PolarDB的刷脏能力是有上限的（取决于磁盘IO能力以及并行刷脏的效率），一旦达到上限，将buffer pool中的脏页落盘的速率也就达到了上限，此时如果业务请求产生脏页的速率大于刷脏的速率，则可能导致buffer pool中的脏页越来越多，进而导致一致性位点延迟逐步加大。
   此时，可以适当调整后台刷脏相关的参数，以提升刷脏效率，包括如下参数：

   • polar_parallel_bgwriter_workers：并行刷脏进程的数量，默认是5个。
     说明 该参数值设置的是默认启动的并行刷脏进程的数据，PolarDB会根据主备延迟情况，动态启停一些并行刷脏进程，可能存在的并行刷脏进程为min (2*polar_parallel_bgwriter_workers, 16)。
   • polar_parallel_bgwriter_delay：并行刷脏进程每轮刷脏之间的休息时间，默认是10ms。

   可以适当增加polar_parallel_bgwriter_workers，适当减小polar_parallel_bgwriter_delay，以提升刷脏效率。

   说明 随着刷脏进程增多，会对集群整体吞吐有一定影响。刷脏占用IO变大，可能导致其他请求写入WAL日志的效率下降，进而影响集群执行SQL的效率。

• 一致性位点延迟会导致checkpoint位点延迟，需要优先排查一致性位点延迟的原因。
• 导致一致性位点延迟的原因均可能导致checkpoint位点延迟，例如业务中有批量数据修改或者刷脏不及时。
• checkpoint执行周期较长，周期时间内有较多的数据修改。您可以适当调整checkpoint_timeout或者max_wal_size提高执行checkpoint的频率。