MySQL5.1 中Innodb事务完整性Bug
今天和 51.com 的 MySQL DBA 景春同学一起遇到了个 MySQL 非常扯淡的Bug:在 5.1 版本中,Innodb 存储引擎如果使用autocommit=0的情况下,单条SQL在执行过程中如果异常中断的话,事务完整性可能无法保证,不论是STATEMENT还是MIXED的binlog_format,都存在相
今天和 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> selectcount(*)fromtest.test;
+----------+
| count(*) |
+----------+
| 1000000|
+----------+
1rowinset(1.71sec)
root@dc-6 : (none)01:36:01> selectcount(*)fromtest.test;
+----------+
| count(*) |
+----------+
| 1000000|
+----------+
1rowinset(1.69sec)
我们再将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> selectcount(*)fromoffer1.test;
+----------+
| count(*) |
+----------+
| 887377 |
+----------+
1rowinset(1.66sec)
root@dc-6 : offer101:44:05> selectcount(*)fromoffer1.test;
+----------+
| count(*) |
+----------+
| 1000000|
+----------+
1rowinset(1.70sec)
Master 和 Slave 两端数据居然出现不一致,在 Master 端已经删除掉了部分数据,在 Slave 端却没有任何变化。执行 deletetest.sh 脚本前后检查 Master 的 Binary Log(SHOW Master STATUS),没有任何变化。这个 Bug 简直是太扯淡了,数据完全没有事务完整性可言了啊。
原文地址:MySQL5.1 中Innodb事务完整性Bug, 感谢原作者分享。

热AI工具

Undresser.AI Undress
人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover
用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool
免费脱衣服图片

Clothoff.io
AI脱衣机

AI Hentai Generator
免费生成ai无尽的。

热门文章

热工具

记事本++7.3.1
好用且免费的代码编辑器

SublimeText3汉化版
中文版,非常好用

禅工作室 13.0.1
功能强大的PHP集成开发环境

Dreamweaver CS6
视觉化网页开发工具

SublimeText3 Mac版
神级代码编辑软件(SublimeText3)

热门话题

游戏bug是什么意思在玩游戏的过程中,我们常常会遇到一些意想不到的错误或者问题,比如角色卡住、任务无法继续、画面闪烁等等。这些不正常的现象就被称为游戏bug,即游戏中的故障或错误。在本文中,我们将探讨游戏bug是什么意思以及对玩家和开发者的影响。游戏bug是指在游戏的开发或运行过程中出现的错误,导致游戏无法正常进行或者出现不符合预期的情况。这些错误可能是由于

Lockwaittimeoutexceeded;tryrestartingtransaction-如何解决MySQL报错:事务等待超时在使用MySQL数据库时,有时可能会遇到一个常见的错误:Lockwaittimeoutexceeded;tryrestartingtransaction,该错误表示事务等待超时。这个错误通常发生在并

随着苹果WWDC发布会2024圆满落幕,不仅揭晓了macos15,其中最受关注的还是苹果iOS18新系统的更新,虽然有很多新功能出现,但是作为苹果iOS18首版不免让人纠结是否有必要升级苹果iOS18,在最新发布的苹果iOS18中又有哪些BUG存在呢?经过真实的使用测评,下面是苹果iOS18bug汇总,一起来看看吧。目前有许多iPhone用户都抢先升级到了iOS18.但各种系统Bug让人难受。有博主表示,升级iOS18要谨慎,因为“Bug多到飞起”。博主表示,如果你的iPhone是

标题:Windows11内存完整性已关闭,如何解决?随着Windows11的推出,许多用户都纷纷升级到了新系统。然而,有些用户在使用Windows11时可能会遇到内存完整性关闭的问题,这会影响计算机的性能和稳定性。本文将针对Windows11内存完整性关闭的问题进行探讨,并提供一些解决方法和建议。一、内存完整性关闭问题的原因Windows11中的内

MySQL事务处理:自动提交与手动提交的区别在MySQL数据库中,事务是一组SQL语句的集合,要么全部执行成功,要么全部执行失败,保证了数据的一致性和完整性。在MySQL中,事务可以分为自动提交和手动提交,其区别在于事务提交的时机以及对事务的控制范围。下面将详细介绍自动提交和手动提交的区别,并给出具体的代码示例来说明。一、自动提交在MySQL中,如果没有显示

InnoDB是MySQL的数据库引擎之一,现为MySQL的默认存储引擎,为MySQL AB发布binary的标准之一;InnoDB采用双轨制授权,一个是GPL授权,另一个是专有软件授权。InnoDB是事务型数据库的首选引擎,支持事务安全表(ACID);InnoDB支持行级锁,行级锁可以最大程度的支持并发,行级锁是由存储引擎层实现的。

InnoDB是一个将表中的数据存储到磁盘上的存储引擎,所以即使关机后重启我们的数据还是存在的。而真正处理数据的过程是发生在内存中的,所以需要把磁盘中的数据加载到内存中,如果是处理写入或修改请求的话,还需要把内存中的内容刷新到磁盘上。而我们知道读写磁盘的速度非常慢,和内存读写差了几个数量级,所以当我们想从表中获取某些记录时,InnoDB存储引擎需要一条一条的把记录从磁盘上读出来么?InnoDB采取的方式是:将数据划分为若干个页,以页作为磁盘和内存之间交互的基本单位,InnoDB中页的大小一般为16

系统bage就是指系统bug;bug原意是“臭虫”,现可用来指代计算机上存在的漏洞,原因是系统安全策略上存在的缺陷,有攻击者能够在未授权的情况下访问的危害;广义上,bug可用作形容各领域范围内出现的漏洞或缺陷。
