[ibd2sql] mysql数据恢复案例004 -- 碎片页/不完整的ibd文件如何使用ibd2sql-2.x解析?

导读

前几天更新了ibd2sql 2.x系列的第一个版本ibd2sql-2.0, 使用方法和之前差不多, 但是对于"坏块"之类的情况支持更广泛了.

有哪些"坏块"场景呢?

1. 某n个page损坏.
2. 文件不完整,如文件被截断,只剩开头部分,但结构完整
3. 只剩下部分索引页(碎片页),结构都不完整了.(也就是只剩下数据页了)

在1.x版本的时候是支持前2种情况, 毕竟只是少部分坏了, 结构还是完整的, 只需要跳过坏的部分即可. 第3种也不算麻烦, 还是全部页都解析即可, 但直到2.x版本才支持, 主要是案例不多,就没有考虑和测试这些情况, 不巧最近有大佬发现有这个问题了, 于是更新下.

测试案例

本案例比较好复现(使用--web功能,确认下pk的pageid,然后手动重定向即可), 故使用模拟环境来演示. 使用方法比较简单:

python3 main.py /tmp/t20250908_test_4_pages.ibd --sdi-table /data/mysql_3308/mysqldata/db1/sbtest2.frm --set rootno=0 --set leafno=0 --force --sql

但是这个选项可能比较多:

/tmp/t20250908_test_4_pages.ibd 需要解析的数据文件, 要求以.ibd结尾.

--sdi-table /data/mysql_3308/mysqldata/db1/sbtest2.frm 指定元数据信息的文件,支持frm和ibd

--set rootno=0 指定root节点的pageno,为了找第一个leafno

--set leafno=0 指定第一个leaf节点的pageno, 是为了获取需要解析的索引的indexid.

--force 一页页的遍历, 即解析所有页, 只要匹配上indexid就解析

--sql 解析结果输出为sql格式.

原理总结起来就是: 遍历所有page,解析匹配的page.

如果数据文件是完整的(含fsp和inode等page), 则需要指定的rootno是4(5.7环境是3), 因为通常第一个索引页就是pk的rootno, 但也不一定(特殊情况就需要专业人员来判断了)

当然实际情况可能不知道表结构信息, 开发也可能无法提供表结构信息, 这时候也得找专业人员来根据数据文件猜测表结构了(这种情况不多,只遇到过几次)

总结

整体和以前使用方法差不多, 也就多了个--set rootno=0 --set leafno=0, 其实有了--force之后可以自动去寻找rootno和leafno的, 但懒得写了(写得越多,bug越多-_-), 有啥问题,请到github上提issue,或者留言.

参考:

https://github.com/ddcw/ibd2sql