本文介绍了日志位点的监控信息和延迟情况,以及延迟的处理方法。
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位点延迟,影响集群的可用性。
通常的处理方法如下:
- 执行以下命令,查询复制槽,确认主备同步是否中断。
查看是否存在select * from polar_replication_slots;
active
为f
的复制槽,如果存在,则说明该备节点与主节点的同步发生了中断,需要进一步排查主备同步中断的原因。说明 PolarDB根据不同的部署形态,其复制槽可能分为两类,即replica和standby。复制槽类型与PolarDB集群中的节点类型相对应,replica节点与主节点共用一份数据,主节点与replica节点的同步如果断开,对主节点的影响较大,需要及时处理。standby节点与主节点类似传统PostgreSQL的主备,各自有独立的数据。复制槽类型可以通过其名称(上述查询中的slot_name
字段)进行区分。 - 如果主备同步正常,执行以下命令,查看主备延迟情况。
查询结果可能存在以下四类延迟: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,进而导致数据库集群崩溃恢复的耗时变长,影响集群的可用性。
通常的处理方法如下:
- 如果同时存在备节点延迟大的情况,请优先处理备节点延迟问题,因为备节点延迟会导致一致性位点延迟。
- 是否存在批量导入或者批量修改数据的场景,导致短时间内产生大量脏数据,此时数据库集群可能无法及时将脏页落盘,导致一致性位点延迟。此类情况属于正常的业务请求导致一致性位点延迟变大,延迟情况应该会在此类业务请求过后恢复到较小的水位。
- 是否存在集群规格和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中的数量。