【 使用环境 】 测试环境
【 OB or 其他组件 】OMS
【 使用版本 】4.2.9_CE
【问题描述】 使用 OMS 配置 PGtoOB 的增量同步任务时， 在源数据某个表发生大量数据改变，但是不是当前增量同步对象时，会导致增量拉取组件的延迟时间无限制增加，直到告警。
- 源端 postgresql 的一个事务会先对某个已开启逻辑复制但是不在当前增量同步任务的表中做大量 update，比如 60W 然后再update增量同步中对象表的某些数据。然后再次大量数据插入那个已开启逻辑复制但是不在当前增量同步任务的表，比如 60W ，再update增量同步中对象表的某些数据。
- 只要发生这样的操作，必定会导致增量拉取组件延迟无限增加，但是不会有任何数据写入到目标对象中。
- 配置为 4 读 4 写，JVM 4～8G。
- 在增量中已设置参数
useBetaListener=true
useSchemaCache=true
- ./connector_utils.sh diagnose 显示 可能存在源端投递数据瓶颈
- ./connector_utils.sh metrics 只有 source 的 delay:1355564ms 这个异常，其他都是 0，heap:1376M/7782M,noHeap:54M/488M threadcount:21,cpu:0.151 syscpu:10.491
2 个赞
淇铭
#3
OceanBase 社区已接收您的帖子，正在跟进中。
刘彻
#8
whitelist发一下，里面是不是只有你要的表，还是通配？
1 个赞
KOMODO
#11
正常任务情况，延迟增大的时候，迁移流量应该会起来，但是目前看迁移流量一直是0。
刘彻
#12
当前延迟的store组件，先排查是否是whitelist中包含了不用同步表
刘彻
#13
ps -ef|grep 7100
应该是有个java进程的，看改进程是否存在fullgc的情况,可能需要切换到ds用户下面(su ds)执行
/opt/alibaba/java/bin/jstat -gcutil pid 1s
KOMODO
#14
没有，都是从之前成功的任务中克隆的，表都验证通过有开复制
淇铭
#16
把logical_decoding_work_mem 调整到 256MB ， 虽然也有延迟，但是在 5 分钟后就开始迁移流量了。
logical_decoding_work_mem 刚刚调整回默认的 64MB ，现在看pg_stat_replication_slots 的信息。
spill_txns | 1325877
spill_count | 1325890
spill_bytes | 2199671044
会一直增长。
后面经过测试调整 logical_decoding_work_mem的大小
1 个赞
