dm 出现 duplicate key ，关于 DM Causality(冲突检测)核心原理的技术咨询

🪐 TiDB 技术问题 备份&数据迁移
1

【 TiDB 使用环境】异地容灾环境
【 TiDB 版本】7.5.1
【复现路径】暂未发现，由于存在偶发性
【遇到的问题：问题现象及影响】

  1. 如图，遇到的问题是 DM 报错 duplicated entry
  2. 初步定位排查是因为前序事务 61662813 是一批 delete ，但出现 invalid connection 未执行，导致后续 insert 相关行数据的时候，提交失败
  3. 姑且不讨论为什出现 invalid connection，但我比较好奇，这似乎跟 DM 文档中提到的复制原理， Causality 相矛盾，这些冲突的行应该分在同一组串行执行才对吧？

Causality 采用一种类似并查集的算法，对每一个 DML 进行分类，将相互关联的 DML 分为一组。具体算法可参考并行执行 DML

  1. 由于是一个业务量极低的 MySQL 同步到 TiDB，目前我们的处置手段是关闭并发，worker-count ，让他串行执行。

【资源配置】N/A
【附件：截图/日志/监控】

企业微信截图_55df5435-7048-44b6-ac7e-29c0a2ee42e0
企业微信截图_55df5435-7048-44b6-ac7e-29c0a2ee42e03438×1966 571 KB

2

关闭并发，可以解决delete失败再去insert报错duolicated entry的问题么？

3

好问题，不是 100%确定，但觉得应该能吧：前序事务invalid connection 失败，在单线程模式，难度不重试就直接应用下面的事务了吗？

4

开了 safe-mode的话， insert 会转成 replace ，就不会有主键冲突的问题了。
可以参考以下链接：
https://docs.pingcap.com/zh/tidb/v7.1/dm-safe-mode#安全模式原理

5

对这我知道。但我们这里不想开这个。。。

6

看文档是有可能解决

7

我们就用了安全模式