我再详细描述一下我们的链路吧
源数据 v6.5.9
目标库 v8.1.1
目的：
源数据通过迁移的方式，更新arm架构体系，更新到 v8.5.4 新版本
做法：
源数据 v6.5.9 通过 cdc 同步到 新版本 v8.5.4，新版本 v8.5.4 再通过 cdc 同步到目标库 v8.1.1
怀疑：
通过 cdc 同步，会把 update 语句合并
到下游新版本 v8.5.4 同步到目标库v8.1.1 时，update 又做了一次合并，导致 update 的条数太大，延迟增长
为什么这样怀疑：
有一个表有很大的 insert 的sql，甚至比我现在这张表的数据量还大，但是仍然平稳
问题点出现在 update 频繁上
你开一下safe-mode试试呢，下游会按照replace去做。这样就知道是不是update的问题了。
https://docs.pingcap.com/zh/tidb/stable/ticdc-sink-to-mysql/
所有参数我都试了个遍了 
现在我从源数据，通过 cdc 同步多一份到测试目标库 v8.1.1，也正常
准备测试双写，写到新版本 v8.5.4，新版本 v8.5.4 再同步到目标库 v8.1.1
我感觉你的问题我可能遇到过，有的时候不知道为啥就同步速度特别，甚至卡住。跟上游的schema有关系。
不过我pause changefeed之后再list一下是可以看到changefeed有warning的，duplicate key。所以换成safe-mode就没问题了。
如果是正常链路，有点延迟我是知道原因的，你的 duplicate 是下游也在写入吧，我们的场景 safe-mode 感觉不太适合，因为 update 太多了，safe-mode 会把 update 拆成两条去跑，等于多了一倍的请求。
我们这个表，一天有 5000w 的数据库，1:3 的比例，就是有 1.5e 的 update