KingbaseES复制冲突中谁阻塞walreplay

最新推荐文章于 2024-06-10 21:57:08 发布

Kingbase 研究院

最新推荐文章于 2024-06-10 21:57:08 发布

阅读量508

点赞数 15

文章标签： java 数据库服务器 linux 前端

本文链接：https://blog.csdn.net/lyu1026/article/details/137883852

版权

背景

回顾一下流复制冲突相关参数：

hot_standby_feedback: 从库反馈给主库快照, 主库vacuum时不回收最老快照之后产生的垃圾，注：备库长查询将导致主库表膨胀。
vacuum_defer_cleanup_age: 当触发vacuum时，延迟指定事务后触发。
recovery_min_apply_delay: 如果将此参数设置为5分钟，则只有在备库时间至少比主库提交时间多五分钟时，备库才会重放每个wal。
max_standby_streaming_delay: 当startup replay stream wal record时, 如果遇到冲突, startup最多等多久。
max_standby_archive_delay: 当startup replay archive(restore command) wal record时, 如果遇到冲突, startup最多等多久。

根据有关视图查询复制冲突次数，冲突是否被阻塞，以及阻塞者

冲突次数
test=# select * from sys_stat_database_conflicts ;
datid | datname | confl_tablespace | confl_lock | confl_snapshot | confl_bufferpin | confl_deadlock
-------+-----------+------------------+------------+----------------+-----------------+----------------
14187 | test | 0 | 0 | 0 | 0 | 0
16053 | security | 0 | 0 | 0 | 0 | 0
1 | template1 | 0 | 0 | 0 | 0 | 0
14186 | template0 | 0 | 0 | 0 | 0 | 0
16387 | test | 0 | 0 | 4 | 0 | 0
17527 | test23 | 0 | 0 | 0 | 0 | 0
(6 rows)

查看当前是否存在冲突，当startup进程的等待事件为空, 表示它被堵塞了，可以理解为此时startup进程什么工作也没做。

当前startup等待事件
当startup在回放wal时, 等待中通常有io等操作. 这种情况不是conflict堵塞。

RecoveryWalAll 通常表示startup进程正在等待wal, 通常此时standby处于未delay状态.对应wait_event_type 是Activity。

startup 可能被哪个查询堵塞了呢
通常是时间越早, 越可能是堵塞startup的query。
或者xmin, xid越早, 越可能是堵塞startup的query。

通常可以使用以下sql进行查询

1、时间最老

select a.* from
(
select *,row_number() over (partition by state order by xact_start) as rn
from sys_stat_activity
where datname=current_database()
and pid<>sys_backend_pid()
and state<>'idle'
) a,
(
select * from sys_stat_activity where backend_type ='startup' and wait_event is null
)b
where a.rn <= 1
order by a.xact_start;

2、或 (事务号最老)

select a.* from
(
select *,row_number() over (partition by state order by least(backend_xid::text::int8,backend_xmin::text::int8)) as rn
from sys_stat_activity
where datname=current_database()
and pid<>sys_backend_pid()
and state<>'idle'
) a,
(
select * from sys_stat_activity where backend_type ='startup' and wait_event is null
)b
where a.rn <= 1
order by least(a.backend_xid::text::int8,a.backend_xmin::text::int8);

可能堵塞了wal apply 的 query 如下

注意, 这样找到的疑似堵塞startup replay的查询, 但是结果不精确。

期待未来有相关sql能关联查询出准确的阻塞者, 可以找到精确的堵塞wal replay的query。

注意目前提供的blocking的系统函数只能用于查询重量级锁的冲突。

备库查看堵塞了多少wal还没有被replay

select sys_is_wal_replay_paused(),
sys_last_wal_receive_lsn(),sys_last_wal_replay_lsn(),
sys_size_pretty(sys_wal_lsn_diff(sys_last_wal_receive_lsn(),sys_last_wal_replay_lsn()));

(1 row)

Kingbase 研究院

关注

15
点赞
踩
11

收藏

觉得还不错? 一键收藏
0
评论
KingbaseES复制冲突中谁阻塞walreplay

背景回顾一下流复制冲突相关参数：hot_standby_feedback: 从库反馈给主库快照, 主库vacuum时不回收最老快照之后产生的垃圾，注：备库长查询将导致主库表膨胀。vacuum_defer_cleanup_age: 当触发vacuum时，延迟指定事务后触发。recovery_min_apply_delay: 如果将此参数设置为5分钟，则只有在备库时间至少比主库提交时间多五分...
复制链接

扫一扫