TICDC ticdc_processor_checkpoint_ts_lag指标算法问题

[TiDBer_Bj7TDCTL]

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

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

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

[Billmay表妹 (表妹)]

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

[TiDBer_Bj7TDCTL]

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

[yilong (yi888long)]

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

[TiDBer_Bj7TDCTL]

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

[neilshen]

@TiDBer_Bj7TDCTL

但ticdc_processor_checkpoint_ts_lag的指标仍然是>1s

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

processor_lag = pd_leader_current_ts - ticdc_current_processor_checkpoint_ts

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

---

@TiDBer_Bj7TDCTL

预设想的是源端开启只读后，同步完成后ticdc_processor_checkpoint_ts_lag即可为0， 能判断是否已完全同步，即RPO=0,但实际上无法进行判断。

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