dm同步是否按binlog顺序执行？

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

dm同步是不是按binlog顺序执行，官方文档我读的比较粗略，说是为了提高QPS会把一些DML操作合并执行，目前出现了一些现象排查不到原因。

现象：dm同步中出现主键和业务主键的冲突，已确定下游数据不是下游产生。
表主键 PRI1(id)、UNK(columnA,columnB)；

查看MySQL的binlog 发现上游短时间内几乎同时一直前后频繁的执行delete、insert 操作
delete(1,aa,123);
insert(2,aa,123);

delete(2,aa,123);
insert(3,aa,123);

delete(3,aa,123);
insert(4,aa,123);

delete…
insert …

大约在一分钟内循环了100次

2

你起码贴一下 DM 的报错吧

3

DM 哪个版本的

4

不是写了就是常规的唯一键duplicate entry冲突报错吗，报错本身看不出问题，binlog skip 跳过binlog或者 resume-task 的安全模式都能重启同步任务。现在想知道的是上游顺利执行的情况下， 为什么下游同步会出现冲突报错

5

是这样看的吗？

bb92bd742a9ee65a78557e91bae6272
bb92bd742a9ee65a78557e91bae62721920×1440 586 KB

6

DM有参数可以调整跳过吧

7

可以跳过，但是想知道是什么原因引起的，下游确认是没有数据写入，上游的mysql也是正常执行，dm突然报主键冲突，究竟是不是因为dm工具引起的

image
image1489×1096 122 KB

8

不保证完全顺序，但是在有可能冲突的情况下会保证顺序，具体可以参考这里：https://docs.pingcap.com/zh/tidb/stable/dm-dml-replication-logic#causality
提供下dm 完整的配置文件看下吧

9

如果你确保没有重复，直接执行恢复 resume-task 我环境的DM如果延迟时间过长，在同步的时候就会经常报错说主键冲突，实际上没有，要手动一直去执行resume。直接恢复继续同步没问题