第20问:删除了数据文件, 该往哪个方向逃跑

发布时间:2020-09-11 浏览次数:158

问题

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


实验

先来建一个测试数据库

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

然后模拟一个业务压力:

现在删掉相关的表文件:

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

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

查看一下 MySQL 占用的句柄:

找到被删除的表:

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

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

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

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

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

看看数据是否正常:

看起来还不错。


实验原理

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

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

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


思考题

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

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



上一篇: 第05期:使用 prometheus 监控 clickhouse 集群

下一篇: 技术分享 | 讨论:MySQL 从库单表恢复

咨询客服 在线咨询
400-820-6580 免费电话