tikv 有一个配置 min_ts_interval 可以调整resolved ts 的推进频率，不过在大量region的情况下可能会影响 cdc 的性能。 set config tikv `cdc.min_ts_interval`="200ms" 另外可以查看grafana 里 Slow Table 那一项看看在哪一个模块引入的延迟比较大

现在 cdc log 里还有大量的 warning 吗？ grafana 可以用 [FAQ] Grafana Metrics 页面的导出和导入 这里面提到的方法导出一下

[image] 这个图上就有同步到了哪个时间点了 不过你 cdc 的版本比较早了， 可能还有其他未知的 bug

应该是 metrics 有异常吧，取了一个 0 时间，猜测是 1970 + 53 = 2023

不会，同步的进度是保存在 etcd 里的， 重启后会从那个时间点重新拉取数据

https://github.com/pingcap/tiflow/pull/8502 这个PR 会处理这种问题

从 log 的信息来看，是 cdc 启动 changefeed 后向 etcd 提交数据一直不成功导致整个同步任务卡住。 请问这个新加的节点就是之前出问题的 owner 节点吗？ 和 PD 间的网络通信什么的都是正常吗？ 有没有集群在出现这个问题的时候其他节点的 log， 尤其的 owner 的 log 另外 pd 的 log 是否也能上传上来？

cdc 是自己在不停重启吗？ 还是人为重启的？如果是tiup 部署的话可以看看 cdc_stderr.log 这个文件里的内容

可以发一下 CDC 其他的监控图吗？ 比如 Dataflow 这个面板

如果不考虑 TiCDC 与 TiKV 的版本兼容问题 从你的尝试的报错信息来看，看起来是你的压缩文件里没有 cdc 这个文件。 可以从官方下载下来 wget https://tiup-mirrors.pingcap.com/cdc-v5.3.1-linux-amd64.tar.gz /root/.tiup/bin/tiup cluster patch tidbcluster cdc-v5.3.1-linux-amd64.tar.gz -R cdc

cdc 依赖的 pulsar client 引入了 keyring 这个库， 而 keyring 这个库会在 init 函数里就去尝试创建 dbus-daemon 我提了一个 https://github.com/pingcap/tiflow/issues/4926 issue 来修复这个问题

没法复现你说的这种情况， 能提供更详细的信息吗？cdc 是从官方下载的吗？ [root@copy-of-vm-ee-centos76-v1 5.3]# pwd /root/5.3 [root@copy-of-vm-ee-centos76-v1 5.3]# wget https://tiup-mirrors.pingcap.com/cdc-v5.3.0-linux-amd64.tar.gz --2022-02-18 11:07:02-- https://tiup-mirrors.pingcap.com/cdc-v5.3.0-linux-amd64.tar.gz Resolving tiup-…

增加对外键的支持。

这个 warning 不影响集群服务，不过看起来是 tikv 新增配置了，找不到这个配置会给 warning。 你可以给operator 提一个issue， 我们来fix一下， 谢谢！

能把你的 tidb cluster 的 yaml 文件发一下吗？