【 TiDB 使用环境】生产环境
【 TiDB 版本】v8.5.3
【复现路径】 创建 cdc 任务
【遇到的问题：问题现象及影响】
我们有 3 个集群，一个很老的版本 v6.5.9，一个新创建的 v8.5.3，一个是 v8.1.1，v8.1.1 的是跨了网络的，延迟大概在 200ms 左右
问题，从 v6.5.9 中用 cdc 同步到 v8.1.1，网络延迟 200ms，cdc 任务正常，同步延时大概在 3s 左右，能接受，然后我在 v8.5.3 中cdc 同步到 v8.1.1 ，网络延迟也是 200ms，cdc 任务的同步延时一直在增长，新版cdc 跟旧版 cdc 在这块上有什么差异吗？
创建任务的命令是
memory-quota = 4294967296
[filter]
rules = [‘d1.t1’,‘d1.t2’,‘d1.t3’,‘d1.t4’]
tiup cdc cli changefeed create --server=http://172.22.xxx.xxx:8300 --config /data/tidb-cdc-config/ticdc-tidb-06.toml --sink-uri=“mysql://xxx:xxx@172.27.xxx.xxx:4000/?worker-count=64&max-txn-row=2000” --changefeed-id=“up-tidb-06-to-down-tidb-03”
建议先排查下外在因素，比如上游的qps，v6.5.9和v8.5.3这两个集群的qps是否相近；v8.5.3同步到 v8.1.1 的时候是否遇到了冲突，检查一下日志；v8.1.1的集群是否达到的瓶颈，或cdc的机器是否有瓶颈
是这样的，我们是想要下线 6.5.9，同步的内容一样，我们做了个同步，6.5.9 全量同步到 8.5.3，我先把 6.5.9 同步到 8.1.1的停了，然后在 8.5.3 的开启 同步到 8.1.1，实际上对下游 8.1.1 的影响应该是要一样的
我看了cdc新架构，是需要手动开启才生效的，说明我现在的架构还是旧架构的 cdc
还有，我其实已经跑了一套这样的cdc了，就是从 6.5.9 同步到 8.1.1，切换到 8.5.3 同步到 8.1.1，量也很大，唯一的区别就是现在跑的这一套，update 比较多，insert 跟 update 的比例大概是 1:3 左右，而我之前做的那一套基本上只有 insert，没有什么 update 语句
cdc组件比较消耗资源的，看看服务器资源有瓶颈了嘛
没有，cdc 资源很闲置，基本 cpu 内存都在 10%以下
延迟一直上升的话是不正常的，需要看下监控分析下问题出在哪个地方 TiCDC 监控指标分析指南
update 语句有可能会非常耗时的，你要在下游看下延迟是不是由于 update 引起的，可以通过调整参数 max-multi-update-row 和 max-multi-update-row-size 或者 batch-dml-enable 来限制下。https://docs.pingcap.com/zh/tidb/stable/ticdc-sink-to-mysql/
你看下下游 tidb 的监控呢？下游写入会有区别吗？
你这里是一条数据也没写到下游吗？看日志有报错吗？或者是卡在某个 ddl 了？
日志没报错，也不是ddl问题，这些都看了
我没看见过
可能是下游刷盘或处理耗时过长
可以试试扩容下游连接池、优化重试策略
应该跟下游没关系，我现在起了一个新的测试集群，网络环境是一样的，版本号也一致，空的集群，也是一样的问题