标签归档：MySQL恢复

mysql drop database 恢复思路

发表于 2025 年 11 月 30 日由惜分飞

今天有一个客户在在虚拟机环境中使用drop database删除一个业务mysql的库,删除之后,第一时间关闭了该虚拟机系统.接到该case请求之后,让客户提供了虚拟机文件(vmdk),通过工具分析,mysql数据库是放在/分区下面的/data里面(lvm结构，xfs文件系统),但是已经看不到他们删除的数据库(mysql一个库对应一个目录)

对于这种情况,我们第一步尝试文件系统层面反删除恢复(对数据库所在分区进行文件系统层面扫描,尝试恢复被删除的mysql表文件),运气不错,找到了一些被删除库的ibd文件

对于这些文件,选择出来客户需要的表,采用discard+import方式进行恢复,类似命令

alter table tablename discard tablespace;
alter table tablename import tablespace;

对于有些部分block损坏的ibd文件,直接这样操作可能会报Data structure corruption错误,这样的情况,可以通过工具解析ibd文件进行恢复

对于有些表,可能在文件系统层面反删除无法恢复,我们通过对磁盘进行mysql的数据块层面扫描(识别在磁盘上没有覆盖的mysql的block),按照pageid的方式进行重组成一个个page文件

然后基于这些page进行恢复需要的表数据

基本上通过上述的方法实现最大限度mysql删除数据的恢复(比如drop database，drop table，truncate table)
如果MySQL数据库恢复问题,需要专业恢复技术支持，请联系我们提供专业MySql数据库恢复服务:
电话/微信:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com

发表在 MySQL恢复 | 标签为 drop database, mysql drop database恢复, MySQL恢复, mysql数据块扫描, mysql碎片 | 评论关闭

应用连接错误,初始化mysql数据库恢复

发表于 2024 年 9 月 9 日由惜分飞

有人在部署一个新网站的时候,写错了配置信息,直接导致原有数据库被清掉,并创建了新库和写入了数据(其实本质就是drop table恢复)
mysql

登录操作系统查看,发现数据库文件在根分区,创建了新库,写入了数据之外,还有几个G的binlog.全部恢复不太可能,最后客户决定需要恢复的2个核心表数据,估计也就几十M的数据.通过os层面进行分析,发现操作系统的反删除恢复无法实现这类数据恢复.最后决定从mysql innodb的的碎片级别记性扫描恢复,通过扫描发现较多碎片
page