今天和 51.com 的 MySQL DBA 景春同学一起遇到了个 MySQL 非常扯淡的Bug:在 5.1 版本中,Innodb 存储引擎如果使用autocommit=0的情况下,单条SQL在执行过程中如果异常中断的话,事务完整性可能无法保证,不论是STATEMENT还是 MIXED的binlog_format,都存在相同的问题,可以重现,屡试不爽。
测试环境如下:
OS:SunOS 5.10 Generic_137138-09
DB:MySQL 5.1.31/32-log Source distribution
binlog_format:MIXED/STATEMENT
tx_isolation:REPEATABLE-READ
测试脚本如下:
#/bin/sh
mysql -uadmin -h127.0.0.1 -pxxx -e”set autocommit=0;delete from test.test;”
[root@dc-5 /tmp]#cat killtest.sh
#/bin/sh
mysqladmin -uroot processlist |grep “admin”|awk ‘{print $2}’|xargs mysqladmin -uroot kill
将删除的脚本放到后台执行,然后执行kill脚本:
[1] 6708
[root@dc-5 /tmp]#./killtest.sh
ERROR 1053 (08S01) at line 1: Server shutdown in progress
real 0m2.901s
user 0m0.007s
sys 0m0.007s
[root@dc-5 /tmp]#
[1]+ Exit 1 time ./deletetest.sh
到Master 和 Slave 两端分别检查数据,看上去很正常:
+———-+
| count ( * ) |
+———-+
| 1000000 |
+———-+
1 row in set ( 1.71 sec ) root @ dc - 6 : ( none ) 01 : 36 : 01 > select count ( * ) from test . test ;
+———-+
| count ( * ) |
+———-+
| 1000000 |
+———-+
1 row in set ( 1.69 sec )
我们再将set autocommit=0拿掉试试看,也就是允许系统自动提交:
#/bin/sh
mysql -uadmin -h127.0.0.1 -pxxx -e”delete from offer1.test;”
[root@dc-5 /tmp]#time ./deletetest.sh &
[1] 6722
[root@dc-5 /tmp]#./killtest.sh
[root@dc-5 /tmp]#ERROR 1053 (08S01) at line 1: Server shutdown in progress
real 0m2.462s
user 0m0.006s
sys 0m0.007s
[1]+ Exit 1 time ./deletetest.sh
再检查 Master 和 Slave 两端的数据:
+———-+
| count ( * ) |
+———-+
| 887377 |
+———-+
1 row in set ( 1.66 sec )
root @ dc - 6 : offer1 01 : 44 : 05 > select count ( * ) from offer1 . test ;
+———-+
| count ( * ) |
+———-+
| 1000000 |
+———-+
1 row in set ( 1.70 sec )
Master 和 Slave 两端数据居然出现不一致,在 Master 端已经删除掉了部分数据,在 Slave 端却没有任何变化。执行 deletetest.sh 脚本前后检查 Master 的 Binary Log(SHOW Master STATUS),没有任何变化。这个 Bug 简直是太扯淡了,数据完全没有事务完整性可言了啊。
原文链接:http://www.jianzhaoyang.com/database/mysql-51-innodb-transaction-bug


被折叠的 条评论
为什么被折叠?



