那天凌晨的报警短信
凌晨三点收到服务器报警时，我正梦见自己掉进无底洞——结果睁眼发现比噩梦更可怕的是生产库的ibd文件损坏。去年某电商平台就栽在这事儿上，花六位数找数据恢复机构，结果对方用开源工具折腾两周，只捞回来30%的订单数据，CTO当场血压飙升到180。你看，有时候专业团队也会翻车对吧？
拆弹专家式检测
连滚带爬打开电脑，先别急着哭啊。像老中医把脉那样，用innochecksum工具给文件做体检，发现报错”page checksum mismatch”，这就像X光片显示骨头错位似的。有意思的是，用hexdump查看文件头时，居然发现部分页面的LSN（日志序列号）出现时间旅行——新数据页的LSN比旧页还小，这不乱套了嘛！
那些坑死人的技术细节
最头疼的是主从库都在报错，但错误还不一样。主库是索引崩了，从库干脆连表空间都认不出来。这时候要是直接上mysqlcheck，信不信它能给你表演个数据蒸发术？有个DBA朋友说他遇到过类似情况，手贱点了repair table，结果把.frm文件修成了空白模板，好家伙直接给数据库做了个格式化。
抢救实录
掏出珍藏的percona-data-recovery-toolkit时，手都在抖。先像考古学家那样从ibdata1里挖出数据字典，再按transaction id把碎片拼起来。中途发现有个30G的大表死活读不出来，急中生智用–use-innodb-force-recovery=6启动实例，趁数据库回光返照的几分钟里火速dump数据。这操作就像给心脏骤停的病人打肾上腺素，其实也没啥把握，但死马当活马医呗。
天亮后的奇迹
当mysqldump进度条爬到100%时，咖啡杯里的冰块都化完了。最终98.7%的数据完璧归赵，剩下1.3%是缓存里的购物车数据——反正用户重新加购就行啦。老板问我怎么做到的，我指着监控图上那个像过山车一样的IOPS曲线说：”看见没，这就是用16小时加班换来的心跳图”。后来运维组多了条新规矩：所有备库必须定期做物理备份，毕竟谁也不想再体验这种半夜”数据库蹦极”了对吧？
数据恢复案例文章所涉及用户姓名（化名）及案例，均已做保密处理。
