行句柄引用了一个已被删除 7346_第20问：删除了数据文件, 该往哪个方向逃跑

问题

我写错了脚本，ibd 文件被删除了，该往哪个方向逃跑？

实验

先来建一个测试库：

我们在这里开启了 innodb_file_per_table，但这个参数并非本实验所必须，只是为了演示方便。

然后模拟一个业务压力：

现在删掉相关的表文件：

可以打开地图 app，选择一个方向开始跑路了...

然而我们还可以挣扎一下，

查看一下 MySQL 占用的句柄：

找到被删除的表：

可以看到，除了临时表，被我们手工删除的表也在其中，对应文件句柄号 54。

现在我们把数据库的流量锁起来(如果使用了支持 offline_mode 的版本，可以设置 offline_mode)： 

现在记录一下表的记录数和校验值，以便跟恢复后的数据比较：

现在通过文件句柄找到消失的数据文件，并将其复制出来(此处注意磁盘空间)：

现在可以将数据库停下来，把恢复的数据复制到数据目录中，启动数据库：

看看数据是否正常：

看起来还不错。

实验原理

Linux 删除文件其实是减少了对文件的使用数，当使用数降为 0 时，才正式删除文件。

所以当我们执行 rm 时，由于 ibd 文件还在被 MySQL 使用，文件其实并没有被真实删除，只是没办法通过文件系统访问。

通过 procfs 查找文件句柄，可以让我们追踪到消失的文件。

思考题

即使我们停止了外部的数据压力，MySQL 也会自主做一些 buffer pool 的刷盘操作。

如果在我们复制数据文件的过程中，MySQL 触发了 buffer pool 的刷盘操作，那我们获得的数据文件不就不一致了么？是否会造成数据错误。

关于爱可生

上海爱可生信息技术股份有限公司是国内开源数据库解决方案领导者、工业互联网高维数据应用创新者。爱可生为产业互联网创新应用提供高性价比、快速落地实现的多数据库管理平台、分布式数据库系统、数据库容器云平台、多地多中心跨云容灾等解决方案。

在工业互联网相关垂直行业，深入分析数据价值，构建数据中台和业务中台的基础软件PaaS平台，用数据技术驱动企业高质量增长。公司产品已被广泛应用于各行业，累计用户超过400家，其中包括工商银行、中国人寿、中国太保、国家电网、上汽集团、中国移动、华为等30多家世界500强企业。

点击此处“阅读全文”，了解更多