KOMODO
#1
【 使用环境 】 测试环境
【 OB or 其他组件 】OMS
【 使用版本 】4.2.8_CE
【问题描述】 使用 OMS 配置 PGTOOB 的增量同步任务后，发现 wal 日志持续增大。
PG 数据库为 15.3
查询复制槽WAL日志相关信息：
SELECT slot_name, active, restart_lsn,
confirmed_flush_lsn, pg_walfile_name(confirmed_flush_lsn),
pg_current_wal_lsn(),
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_insert_lsn(), restart_lsn)) AS delay_size
FROM pg_replication_slots;
| oms_np_6l58twh6g0qo_1742450330646 |
true |
379/DB0706A0 |
379/DB0706D8 |
0000000100000379000000DB |
387/1C0FBFB0 |
53 GB |
| oms_np_6lk4h8obinkw_1742810560622 |
true |
384/87AC06F0 |
384/87AC0808 |
000000010000038400000087 |
387/1C0FBFB0 |
10 GB |
发现 confirmed_flush_lsn 没有更新。
任务中的增量任务正常运行中，也能够正常监控到数据写入并更新到 OB 中。
在官方文档中看到增量同步的描述：
增量同步任务开始后，OMS 社区版会同步源库发生变化的数据（新增、修改或删除）至目标端数据库对应的表中。
PostgreSQL 数据库作为源端的增量同步会自动创建 publication 和 slot。但是需要用户来监测归档文件的磁盘使用情况。OMS 社区版默认每 10 分钟通知更新一次 slot 的 confirmed_flush_lsn，间隔周期支持配置。并且默认归档文件需要保存 48 小时，因此只会通知可清理超过 48 小时以上的归档日志（可配置）。
不知道是否是confirmed_flush_lsn通知上有问题导致数据库未能够清理过期 wal日志？
2 个赞
刘彻
#3
/home/ds/store/store{端口}/log/connector下面的connector.log上传看一下
2 个赞
KOMODO
#7
总共就 2 个在进行的任务，其他任务都已经释放了，而且也杀掉了不用的复制槽
1 个赞
KOMODO
#8
sync-0320-connector.log (42.7 KB)
557 [2025-03-26 10:44:57.599] [INFO] [Thread-6] try to notify clean up archive logs before this lsn:1742930419
558 [2025-03-26 10:44:57.599] [INFO] [Thread-6] not need to notify clean up archive logs, because within archive log keep range
我想知道 这里的1742930419 是哪里来的？
2 个赞
刘彻
#9
改值来自store目录下的drc.topics.xxx这个文件中的key=end
“end”:[4294967295,0,0,74157328,xxx,0]，xxx表示的是store的最大位点时间,如下图所示
store进程会有一个后台定时任务，每隔confirmed_flush_lsn_save_interval_seconds配置秒执行一次（默认5分钟）
archive_log_keep_seconds这个配置是归档保留的秒(默认10分钟)，当前时间-archive_log_keep_seconds得到的时间点之前的归档都会ConfirmLsn
可以搜索关键字"notify clean up archive log which before timestamp" 查看ConfirmLsn的时间
1 个赞
KOMODO
#10
cat drc.topics.POSTGRESQL_np_6l58twh6g0qo_6l591qo4hreo.POSTGRESQL_np_6l58twh6g0qo_6l591qo4hreo-1-0.10.21.11.12-7100:P
OSTGRESQL_np_6l58twh6g0qo_6l591qo4hreo-1-0:0000000008.-.0
{
“gmt”:1742971168,
“begin”:[4294967295,0,0,3877728981040,1742885486,0],
“end”:[4294967295,0,0,3882001863432,1742930419,0],
“source”:""}
1 个赞
KOMODO
#11
但是我在 PG 复制槽信息中并没有发现confirmed_flush_lsn 被更新了。
| oms_np_6l58twh6g0qo_1742450330646 |
true |
379/DB0706A0 |
379/DB0706D8 |
0000000100000379000000DB |
389/5ECE85C0 |
00000001000003890000005E |
62 GB |
| oms_np_6lk4h8obinkw_1742810560622 |
true |
384/87AC06F0 |
384/87AC0808 |
000000010000038400000087 |
389/5ECE85C0 |
00000001000003890000005E |
19 GB |
可以看到，还是379/DB0706D8
1 个赞
刘彻
#12
到oms容器中/home/ds/store/store{端口}/log/connector/connector.log 完整的发一个，按小时归档的
1 个赞
KOMODO
#13
1 个赞
KOMODO
#15
connector.log (11.3 KB)
L_np_6l58twh6g0qo_6l591qo4hreo-1-0:0000000008.-.0
{
“gmt”:1742976839,
“begin”:[4294967295,0,0,3878373933048,1742893680,0],
“end”:[4294967295,0,0,3888555914576,1742972110,0],
“source”:""}
1 个赞
刘彻
#18
zgrep “timestamp to lsn map” connector.*gz
zgrep “notify clean up archive log which before timestamp” connector.*gz
1 个赞
