TICDC ticdc_processor_checkpoint_ts_lag指标算法问题

【 TiDB 使用环境】测试
【 TiDB 版本】5.3.2
【复现路径】
TiCDC在两个集群间进行单向同步

源端开启tidb_super_read_only参数,已无法读写
但ticdc_processor_checkpoint_ts_lag的指标仍然是>1s

【遇到的问题:问题现象及影响】预设想的是源端开启只读后,同步完成后ticdc_processor_checkpoint_ts_lag即可为0, 能判断是否已完全同步,即RPO=0,但实际上无法进行判断。
【资源配置】
【附件:截图/日志/监控】

image


参考下 https://docs.pingcap.com/zh/tidb/stable/system-variables#tidb_super_read_only-从-v531-版本开始引入

源端 tidb_super_read_only 和 tidb_restricted_read_only 都开启的情况下,ticdc_processor_checkpoint_ts_lag指标依旧会大于1s,并且还会小范围波动,例如我现在的环境抽样取值,1.50,2.19,2.15,并没有变为0

  1. 请问上游开启为只读模式的目的是什么? 禁止使用 ticdc 同步数据?
  2. 下游任务连接的是什么? kafka,tidb ?
  3. 请问查看 ticdc 日志,在开启后是否有同步过新信息?
  4. 是否有尝试过 6.2 之后的版本是否有同样的问题?是否存在这种情况
    在执行 SQL 语句之前,TiDB 会检查集群的只读标志。从 v6.2.0 起,在提交 SQL 语句之前,TiDB 也会检查该标志,从而防止在服务器被置于只读模式后某些长期运行的 auto commit 语句可能修改数据的情况

1.开启只读的目的是为了使RPO变为0,用于两个tidb集群之间做容灾演练
2.下游任务连接tidb
3.开启只读后未查看日志是否有同步新信息
4.当前使用版本5.3.2,未使用6.2

processor lag 始终不为 0,是因为它的计算方式,如下

processor_lag = pd_leader_current_ts - ticdc_current_processor_checkpoint_ts

也就是 lag 是相对于 PD leader 上的物理时间的。


这种情况不需要依靠 lag 来判断,直接查看 changefeed checkpoint ts,当 checkpoint 时间戳超过开启只读的时间戳后,就说明已经完全同步了。