使用 DM 同步 MySQL 到 TiDB，主键冲突问题：Duplicated Error 错误

🪐 TiDB 技术问题
1

【TiDB 使用环境】生产环境
【TiDB 版本】8.5.0
【操作系统】Linux
【部署方式】虚拟化
【问题复现路径】无
【遇到的问题：问题现象及影响】使用 DM 同步 MySQL 到 TiDB，主键冲突问题：Duplicated Error 错误。
【复制黏贴 ERROR 报错的日志】“Error 1062 (23000): Duplicate entry '3811909’for key ‘csi separate statement.PRIMARY’”
【其他附件：截图/日志/监控】

2

同步的配置信息看一下

3

有相关命令可以查询吗？

4

这个报错非常明确了，就是csi separate statement这个表的主键3811909，在下游已经有了。所以insert 不进去。

根因就比较复杂了，可能是delete csi separate statement where id= 3811909，就没同步。或者上游删除这个表的数据的时候，使用了truncate table 或者drop table 再create table。这些操作没有同步，所以导致上游删除3811909的时候，下游表中还有这条数据，再插入就报错。

用mysqlbinlog，解析一下上游的binlog，找找为啥会冲突的线索。

如果你确定这个冲突只是偶然的，直接resume task。这个错误就没了。

1 个赞
5

目前看下来，上游MySQL数据没有问题，怀疑是DM同步过程中,在对下游 TIDB 写入的时候导致数据重复问题，这个不知道有没有一些参数可以避免这种情况。

6

传输任务谁配置的，把对应的配置文件看一下。确认下是否有多数据源合并到一个表的情况，还有看下表的主键是否是自增的情况

7

目前在社区看到两个相关的案例：
常见问题排查之 – DM 主键冲突的原因及排查思路 - 小王同学 的专栏 - 专栏 - 常见问题排查之 -- DM 主键冲突的原因及排查思路 | TiDB 社区
记一场DM同步引发的Auto_Increment主键冲突漫谈 - 代晓磊_Mars 的专栏 - 专栏 - 记一场DM同步引发的Auto_Increment主键冲突漫谈 | TiDB 社区

这里也记录一下~

8

根据我的经验，如果是偶尔出这个错误，可以直接resume task。
但是如果resume task还是卡住，这就说明冲突的不是几条。最好找找原因。

dm是严格根据binlog来复制的，从原理上，除非binlog中有delete/truncate/drop这类event没处理，否则不应该出这个问题。当然已知的是dm不会对drop table/database做处理，会直接忽略。

如果你彻底不想管这个问题，那就打开DM安全模式

https://docs.pingcap.com/zh/tidb/stable/dm-safe-mode/

安全模式下，所有的insert 会改写成replace，不会有冲突产生。但对同步正确性的影响就不好评估了。你自己来取舍吧。

9

image
image1544×1740 130 KB

10

每次出现都会有很多条重复记录异常，处理起来也需要一段时间，还是希望能预防或者根治这个问题。

11

我也遇到了这个问题，我是低版本，然后问了tidb的人他说是低版本bug，谁知道你高版本也有。我当时是写了一个脚本，每分钟检查一次，是否有报错PRIMARY关键字，如果有直接执行恢复命令resume-task一下，他就正常了。

12

谢谢，方便分享一下你的脚本吗？

13

1共三个脚本，1个是检查状态tiupquery，1个是监控tiupauto，1个是执行恢复的脚本
tiupauto.sh
#!/bin/bash
#自动监控DM同步出现主键冲突错误，并自动执行恢复命令
date=$(date “+%Y-%m-%d %H:%M:%S”)
monitor1=$(/server/tiupquery.sh 2>/dev/null |grep PRIMARY |wc -l)
if (( ${monitor1} >0 )); then
echo $monitor1,$date,‘xxx库’
/server/tiupresume.sh
fi

tiupresume.sh:
~/.tiup/bin/tiup dmctl --master-addr=192.168.1.1:8261 resume-task mysql-tidb
tiupquery.sh:
~/.tiup/bin/tiup dmctl --master-addr=192.168.1.1:8261 query-status mysql-tidb

14

收到，我看下，谢谢～

15

谢谢，目前开启了安全模式之后，已经正常同步，再持续观察一下同步情况。

16

这样是能过去，如果你对一致性也有要求。

https://docs.pingcap.com/zh/tidb/stable/dm-continuous-data-validation/#dm-增量数据校验

看看这块内容。

还有就是，最好把同步经常出问题的表，分离到一个单独的task里面去，控制这种故障的影响范围。别让这一个表卡住其他的表的同步。