最近发布到市场的版本频繁出现数据库表损坏的情况,具体的现象是select表提示表不存在,但是查看data文件,对应表的ibd和frm文件都在。
通过对多个故障的统计,找到几个频繁出现损坏的表,在分析过程中,发现这些数据表都使用了truncate清除数据,所以怀疑是truncate操作的问题。
设计如下过程来验证这个分析结果:
1、 创建存储过程如下,对一张表模拟频繁调用TRUNCATE
DROP PROCEDURE IF EXISTS prcTest5; CREATE PROCEDURE prcTest5(in ic int) BEGIN declare i int; set i=0; while(i<5) DO truncate table alarmtest5; insert into alarmtest5 select * from port limit ic; set i=i+1; END WHILE;
END;
2、 使用SOAP UI创建压力测试用例
发起的线程为5 测试时间间隔0.5s
3、 使用bat脚本周期taskkill mysqld进程并重新启动
@echo off :loop echo kill taskkill /f /im mysqld.exe echo RegMysqlServer call RegMysqlServer.bat call:sleep 20000 ::调用方法call:sleep [毫秒] (1秒=1000毫秒)
goto loop
:sleep set tmp="%temp%\tmp.vbs" echo wscript.sleep %1>%tmp%&%tmp%&del %tmp% goto :eof
4、 启动测试,持续5-10分钟,关闭测试,打开数据库,发现数据表损坏。
select * from alarmtest5;
提示表不存在,实际到data目录下看,frm和ibd文件都在。
5、 怀疑是多线程导致问题,将线程数降为1,运行5-10分钟后,依然出现数据库表损坏现象。 6、 将存储过程修改为使用DELETE语句,测试线程数5,没有出现数据库表损坏的情况。
DROP PROCEDURE IF EXISTS prcTest4; CREATE PROCEDURE prcTest4(in ic int) BEGIN declare i int; set i=0; while(i<5) DO delete from alarmtest4; insert into alarmtest4 select * from port limit ic; set i=i+1; END WHILE;
END;
7、查看MySQL官方文档,When a table is truncated, it is dropped and re-created in a new .ibd file,结合自测的情况,怀疑是我们每张表使用一个ibd文件,TRUNCATE表是重建ibd文件过程中mysql进程中断,导致ibd文件损坏。
7、 重新创建一个数据库,将innodb_file_per_table = 1参数去掉,所有表共享一个ibd文件。 重复上面的测试,运行15分钟没有出现数据库表损坏的情况。
分析结论
innodb_file_per_table = 1,使用TRUNCATE会重新创建ibd文件,如果这个过程中mysqld进程意外中断,有很大概率出现数据库表损坏的现象。