为了兼容一些使用习惯, cli 会拿pd 参数去 etcd 里查 ticdc 的节点信息,然后拼接 server 参数
可以提供 cdc 卡死时候的堆栈信息吗? 如果可以的话,log 和监控也麻烦提供一下。
ticdc 在 6.5 中对 kafka sink 做了很多性能优化的工作,这些优化不需要配打开。
关于你的报错, 是因为这些参数现阶段要写到 sink-uri 中, 如 --sink-urk “kafka://127.0.0.1:9092/test?max-message-bytes=671088&procotol=canal-json”
正在推进在配置文件中直接支持这些参数
感谢反馈, 这是 cdc 6.2 cli 使用 open api v1时引入 的一个 bug, API 没有返回这个字段。
将在
https://github.com/pingcap/tiflow/pull/8729 里修复。
如果目前需要查看 creator version 的话,暂时可以使用如下 API 查看
curl 127.0.0.1:8300/api/v2/changefeeds/<changefeed_id>/meta_info
tikv 有一个配置 min_ts_interval 可以调整resolved ts 的推进频率,不过在大量region的情况下可能会影响 cdc 的性能。
set config tikv `cdc.min_ts_interval`="200ms"
另外可以查看grafana 里 Slow Table 那一项看看在哪一个模块引入的延迟比较大
[image]
这个图上就有同步到了哪个时间点了
不过你 cdc 的版本比较早了, 可能还有其他未知的 bug
应该是 metrics 有异常吧,取了一个 0 时间,猜测是 1970 + 53 = 2023
不会,同步的进度是保存在 etcd 里的, 重启后会从那个时间点重新拉取数据
从 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 是从官方下载的吗?
[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-…