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

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

同步的配置信息看一下

有相关命令可以查询吗?

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

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

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

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

1 个赞

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

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

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

这里也记录一下~

根据我的经验,如果是偶尔出这个错误,可以直接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,不会有冲突产生。但对同步正确性的影响就不好评估了。你自己来取舍吧。

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

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

谢谢,方便分享一下你的脚本吗?

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

收到,我看下,谢谢~

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

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

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

看看这块内容。

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