十年难得一遇！从数据误删到全量恢复的惊险记录

来自：DBAplus社群

作者介绍

线上的数据库服务我们有完善的备份策略和恢复预案，数据即使被误删除了也是能够恢复的，误删除的数据量恢复只是时间问题。但各位同学自己部署的测试环境或者是在自己电脑中的开发环境的数据库就没有同级别的资源保障了。如果恰好你又把一些不能丢失的数据放到了这种环境中，那么建议要做定期备份，有备才能无患。

今天给大家分享的案例便是这种在线下自搭建环境的一次数据误删除事件。数据不幸被删除和万幸能被全量恢复可谓十年一遇。

测试环境中的一台服务器准备做迁移替换，小 A 同学接到了这个光（危）荣（险）的任务。小 A 选择了直接 rm -rf /mysql 删除这台机器上挂载的数据分区来清理磁盘空间。

不到两分钟，还在挑灯夜战的某位同学就发现一个常用的测试环境无法正常使用了。这时候的小 A 定是心如止（死）水（灰），还是找 DBA 帮忙看看吧。

值班 DBA 小 D 被电话叫起紧急支援，但小 D 登录到服务器上一看也淡（傻）定（眼）了，数据、日志、软件环境统统都被删除了，唯一的一次备份是一年前升级测试环境数据库时做的备份。给 DBA 老 A 打电话吧，问问他的建议。

一旦发生了误删数据先不要慌，停止所有操作，第一时间寻求帮助。即使您是老司机，这时候也要找一位同学帮忙一起观察后续的操作，避免手抖出现再次误操作。

另外要强调的是，在出现数据误删除的服务器上同时只能有一个人操作，其他人应通过桌面共享软件或站在操作人身后观察，避免多人交叉操作出现二次故障。

老 A 在得知数据、日志和软件环境都被删除后，先使用了 ps 命令查看 mysqld 进程是否还存活。

进程还在，这就有戏了，不幸中的万幸。抓紧到 /proc/${pid}/fd 目录看看有没有还未关闭的表可以抢救。

真是太幸运了，这个测试环境里面的表比较少，所有表的数据文件还都是打开状态。数据被找回的概率就很大了。接下来就是如何把这些显示为 deleted 的文件从文件系统中找回了。

在介绍如何找回被删除的文件前，先来介绍一个运维经常会遇到的删除了文件，但磁盘空间不释放的问题。下图是一个模拟的例子，当 test.txt 文件被 tail -f 命令使用时，rm test.txt 并不会释放空间，当将 tail -f 命令 ctrl+c 中止后，磁盘空间才释放。

一个文件在文件系统中的存放分为两个部分：数据部分和指针部分，指针位于文件系统的 meta-data 中，数据被删除后，这个指针就从 meta-data 中清除了，而数据部分存储在磁盘中，数据对应的指针从 meta-data 中清除后，文件数据部分占用的空间就可以被覆盖并写入新的内容，之所以出现删除 test.txt 文件后，空间还没释放，就是因为 tail -f 进程还在一直打开这个文件句柄，文件对应的指针部分由于进程锁定，并未从 meta-data 中清除。由于指针并未被删除，那么系统内核就认为文件并未被删除，因此通过 df 命令查询空间并未释放。

有了之前遇到的类似经验我们知道，MySQL 被删除的数据由于句柄还在打开状态，因此还未完成删除，是可以被找回的，已经关闭的表就无法找回了。找回的方法也比较简单，直接 cat 对应的文件句柄，再通过管道（pipe）或输出重定向的方式即可找回原来的数据文件了。但要注意的是为了保证原来的磁盘不要再被写入新的数据，不要在原分区下做磁盘写操作。这次的环境是部署在云服务器上的，再挂载一块新的云盘到这台服务器上就能把数据文件找回了，找回方式如下图所示：

如果读者使用的是自己的笔记本，可以插一块 U 盘或移动硬盘，将数据拷贝到 U 盘或移动硬盘；如果使用的是物理机可以考虑使用管道给 netcat 命令把数据文件传输到另外一台服务器。如下图所示：

表比较多的话建议写个脚本进行批量修复，注意提前分好目录结构，把对应句柄的文件直接恢复到指定的目录，便于后续处理。数据文件找回来啦！！！

数据文件已经找回了，已经算是完成了一半，至少业务的数据都在这些文件里面，但独立的 ibd 文件是无法被 MySQL 识别的，需要配合表结构定义文件（MySQL 5.7 之前为 frm 文件）才可使用。老 A 咨询了业务同学，他们使用的是开源的服务，可以在其他环境上再部署一套，这样就顺利的拿到了这个服务的建表语句。

MySQL 5.6 以上版本支持通过 ALTER TABLE xxx DISCARD TABLESPACE 和 ALTER TABLE xxx IMPORT TABLESPACE 的方式来删除和导入表空间文件（ibd 数据文件）。而我们这次的测试环境刚好是 5.7 的版本，支持这种语法，真是太幸运了。抓紧找个别的临时环境来建表导入数据就好了。操作方式如下：

笔者在操作的时候使用的账号不是 MySQL 账号，导致第 4 步在引入表空间的时候提示表空间不存在，修改文件属主再重新导入就可以了。提醒大家还是要沉着，不要忙中出错。

完成了上一步千万不要开心太早，由于原来的表空间是未正常关闭的，这种方式恢复的表不可直接使用，数据有无损坏还需要进一步验证。这里老 A 建议把数据使用 mysqldump 出来，然后再恢复到准备迁移的新环境中。精力所限 MySQL 数据逻辑备份和恢复的方案这里就不再讲解了，读者可以自行搜索学习。

备份出来的数据表被导入到新环境后，老 A 请开发同学验证了里面的数据，故障前最新的数据都还在，服务修改配置重新启动功能正常，这时业务终于长出一口气。

老话说“有备无患”，线上数据库服务我们有每天的定时全量备份 ，还有基于 binlog 的实时增量备份。对于自已部署的环境也要加强备份意识。笔记本上的代码要及时提交 git，产品文档要及时上传公司的云盘持久存储。线上数据修改要提前备份修改前的内容，删除数据建议先标记删除再物理删除。