导读
有些场景(比如drop/truncate table)可能需要扫描磁盘才能恢复数据, undrop-for-innodb就很好用, 但我的ibd2sql还不支持啊, 于是就准备给它加这么个功能. 当然得先验证下是否可行以及速度怎么样, 速度不行的话.
原理
表的数据是一页页的放在磁盘(文件系统)上的. 只要磁盘上的数据没有删除,即使逻辑上删除了文件也是能恢复的, 如果时间短的话, 可以从文件系统级别根据inode恢复; 时间长了, 文件就不再完整了, 只能全盘扫的方式恢复了.
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 免费无限量使用 DeepSeek R1 模型☜☜☜
![[MYSQL] python扫描磁盘恢复数据的可行性验证与速度测试](https://cdn.chuangxiangniao.com/www/2025/12/176460013296958.jpg)
那么扫描磁盘的时候我们怎么知道哪部分数据是我们要的数据呢? 这就得先看看数据文件的结构了.
innodb的数据是放在索引上的, 即INDEX_PAGE, 我们只需要扫描到我们需要的INDEX_PAGE即可. 怎么判断是否是我们需要的PAGE呢? 请看:
![[MYSQL] python扫描磁盘恢复数据的可行性验证与速度测试](https://cdn.chuangxiangniao.com/www/2025/12/176460013292605.jpg)
有个2字节的PAGE_LEVEL表示这是叶子节点,即方数据的; 还有个8字节的INDEX_ID表示这个页是对应的某个索引的. 而我们根据表可以找到其对应的索引, 并获取到对应的INDEXID; 既然要恢复, 那么我们肯定就知道要恢复的表了哦. 不知道也没关系, ibdata1/mysql.ibd里面是有记录哪些表是被删除的, 并且有相关的indexid.
立即学习“Python免费学习笔记（深入）”；
那么我们的恢复思路就是: 扫描ibdata1/mysql.ibd获取要恢复表的index; 扫描磁盘寻找对应的PAGE; 然后使用ibd2sql等工具将PAGE中的数据提取出来.
由于linux上一切皆文件, 磁盘也是文件, 所以我们就把磁盘当作普通文件读取即可. 然后将读取的结果进行校验.这种工作一个进程肯定是不够的, 所以支持并发是必须的. 本来还应该校验page是否完整的, 但算了.
![[MYSQL] python扫描磁盘恢复数据的可行性验证与速度测试](https://cdn.chuangxiangniao.com/www/2025/12/176460013250599.jpg)
演示
理论已经有了,就可以试试效果了. 为了方便查看进度, 我做了个动态的进度条(每个进程指定自己在屏幕上的位置,并输出进度).
准备数据
-- 准备测试表和数据create table db1.t20251128_for_drop(id int primary key auto_increment, name varchar(200));insert into db1.t20251128_for_drop(name) values('ddcw');insert into db1.t20251128_for_drop(name) select name from db1.t20251128_for_drop;insert into db1.t20251128_for_drop(name) select name from db1.t20251128_for_drop;-- ....-- 然后干掉它(你就可以跑路了)drop table db1.t20251128_for_drop;![[MYSQL] python扫描磁盘恢复数据的可行性验证与速度测试](https://cdn.chuangxiangniao.com/www/2025/12/176460013262430.jpg)
扫描需要恢复表的indexid
python3 main.py /data/mysql_3306/mysqldata/mysql.ibd --delete --set table=tables | grep t20251128_for_droppython3 main.py /data/mysql_3306/mysqldata/mysql.ibd --delete --set table=indexes | grep 463![[MYSQL] python扫描磁盘恢复数据的可行性验证与速度测试](https://cdn.chuangxiangniao.com/www/2025/12/176460013328003.jpg)
我们这里扫描出2条是因为第一次建测试表的时候忘记加主键了, 其实不影响的, 但我还是删除了重建. 经过上面的步骤我们得到indexid为254
扫描磁盘获取数据
然后我们就可以根据上面拿到的indexid去扫盘了.
python3 scan_drop_table_demo.py --device /dev/vda1 --indexid 254 --parallel 8![[MYSQL] python扫描磁盘恢复数据的可行性验证与速度测试](https://cdn.chuangxiangniao.com/www/2025/12/176460013350392.jpg)
![[MYSQL] python扫描磁盘恢复数据的可行性验证与速度测试](https://cdn.chuangxiangniao.com/www/2025/12/176460013340665.jpg)
![[MYSQL] python扫描磁盘恢复数据的可行性验证与速度测试](https://cdn.chuangxiangniao.com/www/2025/12/176460013358468.jpg)
看起来还是比较绚的(艹,忘记加点色了).
第一列是 进程逻辑ID,
第二列是 进度条
Reclaim.ai
为优先事项创建完美的时间表
90 查看详情 
第三列是 进度百分比
第四列是 速度
第五列是 这个进程扫描磁盘的起止位置
第六列是 这个进程扫描到多少个匹配的page了.
![[MYSQL] python扫描磁盘恢复数据的可行性验证与速度测试](https://cdn.chuangxiangniao.com/www/2025/12/176460013394015.jpg)
花了151秒扫描了40GB的磁盘, 速度大概是271MB/s, 还行, 反正支持并发,上限还是很高的.
解析扫描的page
最后我们就可以解析扫描出来的结果了, 我这里忘记显示输出文件了. 没事, 反正是个demo
python3 main.py 0000000000000254.page.ibd --sdi /data/mysql_3306/mysqldata/db1/t20251128_for_drop_new.ibd --sql --limit 10 --set leafno=0 --set rootno=0![[MYSQL] python扫描磁盘恢复数据的可行性验证与速度测试](https://cdn.chuangxiangniao.com/www/2025/12/176460013341922.jpg)
看起来没得问题, 但数据应该不全, 毕竟我这个测试环境比较闲,那文件系统肯定老早就给我回收一部分了,可恶!
源码见文末
总结
所以,python扫描磁盘效果还是不错的, 速度也不错.
在能扫描磁盘后, 我们能恢复mysql的范围就更广了, 基本上数据物理上存在我们就能恢复, 感觉自己棒棒哒!
这个脚本起始很早就写好了的, 但之前测试的时候始终未成功, 后来发现我测试的那个环境的innodb-page-size是4K, 而我这个demo的pagesize是写死了的16K….. 就TM离谱!
由于只是测试demo脚本, 不建议用于生产, 可等我后续给它丫集成到ibd2sql后再考虑生产
附源码:
#!/usr/bin/env python3# write by ddcw @https://github.com/ddcw# 测试扫描磁获取相关Indexid的page的测试例子,验证可行性和效率import osimport sysimport statimport timeimport structimport shutilimport argparsefrom multiprocessing import ProcessPAGE_SIZE = 16384def print_error_and_exit(msg,exit_code=1):msg += ""sys.stdout.write(msg)sys.exit(exit_code)def print_info(msg):msg += ""sys.stdout.write(msg)def format_size(n):if n < 1024:return f'{n} B'elif n < 1024*1024:return f'{round(n/1024,2)} KB'elif n < 1024*1024*1024:return f'{round(n/1024/1024,2)} MB'elif n < 1024*1024*1024*1024:return f'{round(n/1024/1024/1024,2)} GB'elif n Q',indexid)hc = 0while end > readed_size:start_time = time.time()readsize = buffering-len(buff)buff += f.read(readsize)if len(buff) < 16384:breakreaded_size += readsizeoffset = 0while True:data = buff[offset:offset+16384]if len(data) start else file_sizeper_size = (end-start)//parallel//step*step+stepindexid = parser.INDEXIDoutput_filename_pre = '/tmp/' + str(indexid).zfill(16)+'.page'for x in range(parallel):output_filename = f"{output_filename_pre}{'.'+str(x) if parallel > 1 else ''}"pd[x] = Process(target=worker,args=(x,filename,start+x*per_size,per_size,step,indexid,parser.BUFFERING,output_filename,screen_size))for x in range(parallel):pd[x].start()for x in range(parallel):pd[x].join()stoptime = time.time()sys.stdout.write(f" 33[{parallel + 3};{0}HFinish! cost:{round(stoptime-starttime,2)} sec.")sys.stdout.flush()if __name__ == '__main__':main()以上就是[MYSQL] python扫描磁盘恢复数据的可行性验证与速度测试的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1050955.html
微信扫一扫 
支付宝扫一扫 
