本文介绍了日志位点的监控信息和延迟情况,以及延迟的处理方法。

PolarDB中存在以下几个比较重要的WAL日志位点:
  • 主节点当前日志写入位点,可以通过pg_current_wal_insert_lsn()函数查询。
  • 所有备节点中最小的日志回放位点,可以通过polar_oldest_apply_lsn()函数查询。
  • 主节点的一致性位点,可以通过polar_consistent_lsn()函数查询。
    说明 关于一致性位点的背景介绍,请参见一致性位点
  • checkpoint位点,即数据库崩溃恢复时回放日志的起始位点,可以通过pg_control_checkpoint()函数的redo_lsn字段获取。

监控方法

您可以通过以下命令监控相关位点以及延迟情况:
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;
说明 以上命令中polar_*函数需要安装polar_monitor插件后才可以使用。

备节点回放延迟

根据以上监控结果,如果WP-AP较大,说明备节点回放延迟较大,需要及时关注。

备节点回放延迟会导致如下问题:
  • 主节点无法重用WAL日志,导致WAL日志大量堆积,数据库集群占用的存储空间上涨。该异常可以通过监控数据库集群的存储空间或WAL日志存储空间发现。
  • 由于备节点查询存在较大的延迟,导致备节点无法查询到主节点最近更新的数据。
  • 如果使用了读写分离组件(Proxy),Proxy可能将所有请求都路由到主节点进行处理,无法发挥读写分离的作用。
  • 导致一致性位点和checkpoint位点延迟,影响集群的可用性。
通常的处理方法如下:
  1. 执行以下命令,查询复制槽,确认主备同步是否中断。
    select * from polar_replication_slots;
    查看是否存在activef的复制槽,如果存在,则说明该备节点与主节点的同步发生了中断,需要进一步排查主备同步中断的原因。
    说明 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进程的运行状况,视具体情况进一步排查。
    根据以上命令,查询延迟较大的备节点,进而排查对应备节点延迟较大的原因。

一致性位点延迟

如果WP-CP较大,说明一致性位点延迟较大,需要及时关注。一致性位点延迟会导致无法及时有效地执行checkpoint,进而导致数据库集群崩溃恢复的耗时变长,影响集群的可用性。

通常的处理方法如下:
  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位点延迟

如果WP-REDO较大,表示checkpoint位点延迟较大,checkpoint位点直接影响集群Crash Recovey时回放的日志量,回放的日志量越多,耗时越长,对集群的可用性影响可能越大。

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

其他监控项

  • 脏页数量
    执行以下命令,查看Buffer Pool中脏页数量。
    select size from polar_flushlist;
    polar_flushlist记录FlushList的一些统计信息,上述查询结果中的FlushList中的buffer的数量,仅脏页才会放入FlushList中,因此,size * 每个页的大小(默认为8 KB)即为buffer pool中脏页的大小。
  • Copy Buffer Pool
    执行以下命令,查看Copy Buffer Pool中的buffer数量:
    select copy-release as cbuf_size from polar_cbuf;
    polar_cbuf记录Copy Buffer Pool的一些统计信息,其中copy表示拷贝进Copy Buffer Pool的数量,release表示释放的buffer的数量,两者相减即为当前仍在Copy Buffer Pool中的数量。