-4006-505-646

MySQL数据库中的库文件突然丢失成功恢复案例


一、环境描述

操作系统:CentOS 6.4_x86_64

数据库:MySQL 5.6.15

文件系统:ext4

数据卷大小:5.8 TB

二、故障描述

   正常使用中,MySQL数据库中的用户库fwpt_kr突然丢失。文件系统中此数据库对应文件夹及数据文件消失,此数据库不可用。

三、故障分析

   通过对原存储数据的卷的镜像进行分析,先解析ext4文件系统,从文件系统中检测不到丢失的fwpt_kr文件夹,也没有对应的文件。

   通过在镜像中对mysql数据页碎片进行扫描,获取到大量数据页面,说明数据还存在于磁盘自由空间中。

四、恢复过程

1. 对原数据卷进行镜像备份,备份到新存储,备份大小5.8TB。

2. 对此镜像文件进行碎片扫描,并把扫描到的碎片信息存储到中间数据库中。

3. 分析扫描到的碎片,对这些信息进行筛选和归类,拼接出有效数据页,并导出为中间数据,之后对其处理。

4. 对上面导出的中间数据集进行分析,还解析里边的mysql系统表,获取用户表的位图信息和结构信息。

5. 分析用户数据库的结构,对其中的表进行定位和解析。

6. 把解析出的表数据转换成插入脚本,并导回新库中。

7. 如导回的数据有误,继续上面步骤,修复表数据。 

五、数据验证

   把恢复出的表数据,移交给应用开发人员,配合其验证数据正确性和完整度。通过协同的验证,验证有误的数据,再进行进一步修复,并进行再次验证。最终需要的重要表数据都通过验证。

六、恢复总结

   根据对故障分析和对数据的扫描,发现此故障比预估的误删除库更加复杂,此数据库的系统表信息全部丢失,这跟一般的误删除库底层表现很不一样,同时这也增加了恢复难度。由于对MySQL数据库底层结构足够了解,并且有处理过类似故障类型的经验。所以整个恢复过程中根据实际需求和数据实际特征,进行了多次算法调整,最终恢复出需要的数据。通过验证客户需要的重要数据全部恢复。

   根据对故障的分析和处理情况,产生故障的原因可能有下面几种:

     1. 根据文件丢失表现,可能与系统中ext4 文件系统缓存bug有关.

     2. 丢失的表在底层残缺的表现为表名乱码,可能是mysql的未知bug引起。

     3. 可能的某些病毒或恶意代码造成的库数据丢失。


4006-505-646