MySQL UPDATE顺序导致主从同步异常问题一例

前些天公司论坛的一个从数据库报了一次Duplicate entry(1062)错误,现在的论坛都搭建了双从库,而登录另一台从库看到是同步正常的,这就有些诡异了。起初以为是mysql版本问题导致,但是检查后发现同步正常的那台机器的mysql版本跟主库不一致,而恰恰是出问题的机器与主库的版本是一致的。出错的语句是一个合并帖子的UPDATE操作,由此引出了这个问题,问题最初是顺安发现的。

1 问题描述

论坛从Discuz 7.2升级到X3.2,并基于Discuz X3.2版本做了许多的定制和插件开发,用到的MySQL版本为5.1,存储引擎为MyISAM,binlog_format为STATEMENT。这个问题简单描述就是:论坛里面有个帖子表,在合并帖子的时候会对帖子的位置信息进行更新,在执行位置更新语句的时候主库和另一个从库没有报错,而其中一个从库报错了。为了方便描述,这里先创建一个测试表post,


CREATE TABLE `post` (
  `i` int(11) DEFAULT NULL,
  `p` int(11) NOT NULL,
  PRIMARY KEY (`p`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

然后在里面插入几条数据 insert into post values (1,1), (2,3), (3,4)。在论坛里面合并帖子的时候会执行一个帖子位置更新的操作 update post set p=p+1;,这样我们看到这个操作就报错了。


mysql> insert into post values(1,1), (2,3),(3,4);
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> update post set p=p+1;
ERROR 1062 (23000): Duplicate entry '4' for key 'PRIMARY'

mysql> select * from post;
+------+---+
| i    | p |
+------+---+
|    1 | 2 |
|    2 | 3 |
|    3 | 4 |
+------+---+
3 rows in set (0.00 sec)

2 解决方案

看到这里相比大家都发现了,这是因为UPDATE的顺序问题导致出现了键值冲突,因为我们并没有指定UPDATE的顺序,而恰好我们看到的顺序是按照p=1, 3, 4的顺序来执行,因此,第一条记录(1,1)成功更新成了(1,2),而执行到p=3的时候,因为p+1=4与已有的值4冲突报错。要解决这个问题的方式也很简单,在更新位置信息时指定顺序为DESC,这样从大到小执行更新就不会出错了,update post set p=p+1 order by p desc(ps:之前很少在UPDATE语句中用ORDER BY 语句,还以为不支持,查了下手册确认了下是OK的)。MySQL手册里面还特意提到过这个问题,可能Discuz开发人员没有注意到这一页,当然Discuz里面数据库操作有许多有性能问题的SQL语句,我们已经修过很多BUG了。

If an UPDATE statement includes an ORDER BY clause, the rows are updated in the 
order specified by the clause. This can be useful in certain situations that might 
otherwise result in an error. Suppose that a table t contains a column id that has 
a unique index. The following statement could fail with a duplicate-key error, 
depending on the order in which rows are updated:

UPDATE t SET id = id + 1;

For example, if the table contains 1 and 2 in the id column and 1 is updated to 2 
before 2 is updated to 3, an error occurs. To avoid this problem, add an ORDER BY 
clause to cause the rows with larger id values to be updated before those with 
smaller values:

UPDATE t SET id = id + 1 ORDER BY id DESC;

3 几个问题

  • 1)MySQL的SELECT和UPDATE语句的默认顺序是怎么样的?

    这个问题mysql手册中也有提到过,SELECT/UPDATE语句的默认顺序跟数据文件以及存储引擎等相关,在写SQL语句的时候千万不要依赖默认顺序,如有需要,请加上ORDER BY.

  • 2)为什么版本一致,但是主库没有报错而从库报错?

    这就是第一个问题里面说的,虽然主库和从库版本相同,但是由于数据组织不同导致主库UPDATE的顺序跟从库不同,巧合的避过了重复键的错误。如果本身主库和从库的UPDATE顺序一致,那么主库本身就会只执行部分更新并报错,从之前的那篇 MySQL binlog格式解析可以知道,这种情况下binlog里面是会记录一个错误码的,那么从库在执行的时候虽然也会有一个 Duplicate entry(1062)错误,但是对比binlog的错误码是一致的,所以同步并不会出错。

参考资料

http://dev.mysql.com/doc/refman/5.7/en/update.html

欢迎加入 CSDN技术交流群:(点击即可加群)QQ群:681223095。

因经常有人留言,未能及时查看到和回复,所以特建此群,以方便交流。方便问题讨论,有问题和没有问题的小伙伴均可加入,用作自我学习和共同进步。本博主不一定长期在线,但是qq群里会有很多热心的小伙伴,大家一起讨论解决问题。
右边的二维码是公众号。关注公众号,更多学习内容给予推送,争取每日更新

这里写图片描述

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
MySQL主从同步异常是指在主从复制过程出现的错误或异常,可能导致主从数据不一致或同步延迟。对于这种情况,通常可以采取一些措施来解决或修复。 首先,我们可以通过检查MySQL主从配置文件、网络连接、用户权限等方面,排查配置问题和网络问题。确保主从服务器之间网络连接正常,主从配置正确,且用户权限设置正确。 其次,我们可以尝试重启MySQL服务来恢复主从同步。通过在主服务器上执行"FLUSH TABLES WITH READ LOCK"命令,锁定表并停止写入操作,然后重启主服务器和从服务器。这可以帮助重新建立主从同步关系。 如果以上方法未能解决同步异常问题,我们可以考虑使用一些专门用于修复MySQL主从同步问题的软件工具。例如,Percona Toolkit提供了一些工具,如pt-table-checksum和pt-table-sync,可以用于检查主从数据的一致性并修复不一致的数据。这些工具可以帮助找出数据不一致的表和行,并进行同步修复。 此外,如果主从同步异常是由于网络故障或服务器宕机等硬件故障引起的,我们可以考虑恢复数据库备份来修复同步异常。通过使用备份数据重新构建主从复制关系,可以确保数据的一致性,并尽量减小同步延迟。 总而言之,针对MySQL主从同步异常,我们可以通过检查配置、重启服务、使用专门工具、恢复备份等方式来解决或修复。不同的情况可能需要采取不同的策略,具体方法取决于问题的原因和具体环境。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值