MySQL数据库丢失？专业抢救数据成功！

客户哭着找上门的时候

那天下午刚啃完半拉煎饼，某创业公司CTO直接冲进办公室，说他们MySQL主库突然崩了——前一天外包团队做数据迁移，rm -rf手滑把生产环境给清空了。更绝的是，他们之前找的某数据恢复公司折腾两天，最后就掏出来几个残缺的ibd文件，连表结构都拼不全。说实话啊，听到"外包团队"四个字我就开始太阳穴突突跳。

开盘检测比想象中还糟

接到硬盘第一件事就是上PC-3000看底层状态，好家伙，文件系统被覆盖了将近40%。MySQL这玩意儿吧，就算.ibd文件还在，要是frm文件没了就跟丢了地图的寻宝游戏似的。特别坑的是他们用的还是Antelope格式，这种老古董现在连官方文档都懒得写了。不过干我们这行的都知道，越是这种"老破小"反而容易找到特征值。

最头疼的不是技术问题

真正麻烦的是他们服务器开着自动备份，但备份脚本写错了路径——所有备份都往/tmp里扔，系统重启直接清零。这种魔幻操作我每年至少碰到七八次，有时候真想问问某些程序员，你们写脚本都不做灾难测试的吗？恢复过程中最耗时的其实是拼凑事务日志，innodb的undo log被切割得七零八落，得像玩拼图似的把时间线捋顺了。

三天两夜没白熬

最后从硬盘底层捞回来92%的数据，包括他们最要命的用户支付流水表。有意思的是恢复过程中还发现他们数据库早就有坏块了，这次事故算是提前引爆了炸弹。交数据的时候我多嘴说了句："下次记得用XtraBackup啊"，结果CTO当场下单了二十套授权——看吧，有时候灾难反而是最好的安全教育。