search 2013 adfgs
作者:Sky.Jian | 可以任意转载, 但转载时务必以超链接形式标明文章原始出处 和 作者信息 及 版权声明
链接:http://isky000.com/database/mysql-51-innodb-transaction-bug | del.icio.us | Twitter it

今天和 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

测试脚本如下:

[root@dc-5 /tmp]#cat deletetest.sh
#/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脚本:

[root@dc-5 /tmp]#time ./deletetest.sh &
[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 两端分别检查数据,看上去很正常:

root@dc-5 : (none) 01:35:43> select count(*) from test.test;
+----------+
|
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拿掉试试看,也就是允许系统自动提交:

[root@dc-5 /tmp]#cat deletetest.sh
#/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 两端的数据:

root@dc-5 : (none) 01:40:30> select count(*) from offer1.test;
+----------+
|
count(*) |
+----------+
887377 |
+----------+
1 row in set (1.66 sec)
root@dc-6 : offer1 01:44:05select 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 简直是太扯淡了,数据完全没有事务完整性可言了啊。

, , ,

已经有4个回复

  1. 深圳公交查询网 Says @ 09-03-24 3:04 pm

    纯技术博客 牛X啊 这个主题好熟悉.

  2. coway Says @ 09-05-2 3:13 am

    Hello,

    Did you try row based replication? Since you kill the process and the transaction is not committed, no rows are deleted from the master. Under RBR, no replication logs should be sent to the slave.

    It may be a bug.

Trackbacks & Pingbacks

  • Alibaba DBA Team » MySQL 5.1 中 Innodb 的事务完整性Bug

    [...] 原文链接:http://www.jianzhaoyang.com/database/mysql-51-innodb-transaction-bug [...]

  • DBA world » Blog Archive » MySQL 5.1 中 Innodb 的事务完整性Bug

    [...]  原文出处:http://www.jianzhaoyang.com/database/mysql-51-innodb-transaction-bug Tag: Innodb, MySQL 上一篇 CBO对于Oracle SQL执行计划的影响(之二) 喜欢DBA world的文章,那就通过 RSS Feed 功能订阅阅读吧! Mysql测试一:Mysql Slave群切换MasterMysql测试二:DRBD+Mysql 高可用方案设置测试MySQL上的WebChart你理解Explain命令输出中的filesort了么改良版本mysqldump来备份MYSQL数据库关于分组序号在MySQL中的实现数据水平切分后的主键全局唯一方案用Amoeba构架MySQL分布式数据库环境 [...]

看完了要说点啥么?