DM同步从上周五11点开始一直延迟，以为是上午有什么大数据量导致的，等晚上会恢复，结果一直延迟。从11点延迟半小时到下午延迟了3个小时。晚上七八点延迟5小时，第二天早上9点延迟半小时，以此循环。
这是日志中的一部分数据：
[2024/01/22 10:03:31.822 +08:00] [WARN] [db.go:285] [“execute transaction”] [task=tccore] [unit=“binlog replication”] [query=“[INSERT INTO tc_xxt.t_table_name xxxxxxxx~~~2024-01-22 10:02:41 2024-01-22 10:02:41] [0ace7bb1493d4b619dca5aaf92d83b60 d678eb18d236458aa61dd282e0bcf347 5b002060e9d1423cb216168b9cd8a9af …”] [“cost time”=12.231926599s]
做过的操作：之前数据库写冲突比较多，查询数据库模式结果为空，然后周五上午修改为悲观锁，然后开始延迟。周六下午的时候修改为空。但是延迟没有恢复。
可以看下下游TiDB的慢SQL分析下
2 个赞
把语句提取出来看看慢在哪了
不过要先看下数据库的性能负载，最近这段时间是不是异常
这个好几个月都是这样子。
+1，是不是这个表有唯一索引，还开启了multiple-rows: true?
这个参数在哪看、同步好几个表。全库同步。不只是这一个表
额，忽略这个参数吧，刚注意到你的版本竟然是4.0.2，还不支持设置multiple-rows。。。
只看慢的表的表结构是否有唯一索引，以及下游TiDB集群的负载情况吧。
同步变慢，如果DM任务没问题的，大概是在下游有些地方需要优化。
看看下游集群的读写延迟情况、tikv热点，和慢查询。从这些地方也入手先排查一下。
1 个赞
这些都有。都是业务表。主键索引 日期等几十个字段，，负载我看都是正常的 2-3左右。 cpu 一知道100-200% 16核应该是比较低的。
恩，目前只能是tidb问题了。或者源端有大量数据突然增多
楼主重点分析一下下游集群慢查询的情况
看了很多，大部分的都是insert慢，paramer阶段。看了写文档说这个阶段都是写冲突。
然后数据库是2.0升级到4.0.2版本的。应该是乐观模式，因为前几天有写写冲突影响业务了，周五上午的时候改成悲观模式了。结果就导致这个延迟严重。周六又改成乐观模式了。周一看样子恢复了。
1 个赞
如果性能没有特别大的编译，那应该要么还是设置问题或者sql本身问题
建议还是先判定sql本身的问题
sql全都是insert values 这种 指定的固定值，传输过来的定量参数
业务访问集群的流量情况有变化吗？看你的现象描述可能和业务的访问比较相关
1 个赞
业务没什么变化，这个cost time时间一直是1-12s左右。。
这个延迟我这边大概猜测是因为我周五早上修改为悲观锁就开始出问题，然后周六修改为空，周一凌晨恢复同步正常。
嗯，如果条件允许的话可以在测试环境模拟并验证下结论，避免再次在生产环境遇到类似问题
正常的同步不应该有这么多写冲突。
数据同步中的写冲突多，就要额外注意：是不是分片合并，然后合并表的主键没有添加分片键造成的写入冲突。
这种情况，就是同步逻辑错误了。