MySQL案例 duplicate primary
发布时间：2023-02-20 13:21:02 所属栏目：MySql 来源：互联网
导读：结论先行: 最终只是解决了这个问题, 没有找到根本的原因, 本文只有针对这个问题的分析和思考; 现象: 在Master-5.0.X与Slave-5.7.17进行同步的时候, slave worker抛出了一个错误, duplicate primary; 分析: 看上去是个很正常的报错, 主键重复, 出现这个这个问
|
结论先行: 最终只是解决了这个问题, 没有找到根本的原因, 本文只有针对这个问题的分析和思考; 现象: 在Master-5.0.X与Slave-5.7.17进行同步的时候, slave worker抛出了一个错误, duplicate primary; 分析: 看上去是个很正常的报错, 主键重复, 出现这个这个问题的可能性有不少, 不过这次的问题比较蹊跷, 因为这个slave是用mydumper新做的, 刚开始同步几条数据就报错, 有点奇怪; 由于使用了auto_increment作为主键, binlog会在记录这类语句的时候在binlog的statement之前注明主键的具体值; 从binlog的内容来看, 这个语句明显不应该是插入pk=13的记录, 应该是91391才对; 那么如果从Master把这条数据单独导出来, 直接手动导入的话, 跳过这个错误, 也是能解决问题; 看了一眼relaylog, 到导出数据的时候, 都没有再对这条数据进行修改, let's go~ PS: 因为Master的写入很少, 所以才能这么干, 繁重业务的话, 就跳过这种办法吧... 最后才把疑点放到这张表的触发器上; 这个触发器是用来做表字符集转换的, 以前在别的数据库中也用到过,这次报错的信息也不是触发器的内容,按道理来说应该是没啥问题的; 不过除了触发器, 好像真没有什么有可能会出问题的地方了, 试着删了这个触发器之后, 发现一切正常了...... 思考: 首先遇到这个问题的时候, 去查了relaylog, 第一时间的猜测是binlog的问题或者是表的问题, 因为从报错信息里面可以看出来, sql_thread在重演这一条语句的时候, 认为pk=13, 但是binlog里面记录的明显是91391; 那么就有可能是sql_thread在这一块event的时候, 没有认出来这个insert_id=91391的信息, 直接忽略掉了 之后发现binlog是statement, 这个语句并没有把所有列的值进行显式的赋值, 而且和后面的另外一条语句组成了一个事务, 如果把完整的信息都列出来, 或者把这个语句拆出来做成一个单独的事务, 是不是就没问题了? 所以之后单独把那一行数据导出来, 再尝试插入到表里面, 不管是source sql文件还是insert...select也不行; 从这几次尝试之后, 基本也能判断不是SQL的问题了; （编辑：莱芜站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
