终于让.idb文件中的MySQL数据重见天日
--James Qi 2010年6月1日 (二) 12:00 (CST)
从5月20日早上数据库信息丢失后，这些天我把其它的事情都摆在旁边，主要工作就是设法尽快恢复数据，还拉了几位同事一起来帮忙。
手头上只有从innodb file-per-table目录下复制出来的.frm和.ibd文件，按常理是无法恢复了。找了前几天的备份，大部分网站数据库从.sql文件中恢复了，而查号吧的.sql文件中备份的table竟然不全，那我们最重要的网站可能就此毁于一旦！后来在另外一台服务器上偶然找到去年9、10月份的数据，但退回半年前就损失太大了。所以无论如何都要设法恢复现在的数据！
在网上找了老外写的资料Recovering an InnoDB table from only an .ibd file.，有办法恢复，上周末就按照那个办法把41个表中的30多个恢复了，但剩下的5个表却总是报错，结果上周我们就不断尝试，修改.ibd中所有table space id号码、编程增加log sequency number、更换my.cnf中不同的force级别、添加很多table来匹配table space id等。
因为增加log sequency number需要时间很长，上周中途我们也尝试用innodb-tools来修复，可以恢复大部分数据，但blob类型以及汉字支持都存在问题，所以最后出来的数据有缺失，没有能实际使用。
尽管遇到各种问题，但我相信数据并没有丢失，一定可以设法恢复的，只是时间早晚。上周还写邮件给innodb-tools开发者公司，他们提供mysql数据恢复服务业务，我询问了价格，450美元/小时，2小时起步。我们如果无法自己恢复的话，花钱也要找他们帮忙，只是这个价格确实高了些，特别是不知道多长时间能恢复。我们自己已经花费了上百个小时，按照这样的价格就是几万美元了。
这个周末通过添加很多table来匹配table space id又找出了一个关键表的数据，剩下的4个表操作时却一直报内存错误，昨天下午找了两位同事陪着一点一点测试，最后发现是字段定义稍有不同引起的，在修改了表结构后，终于是将所有数据都找出来了！！
昨天连夜进行了导出临时库、导入正式库，数据量很大，到凌晨导了几个小时还没有完就休息去了，今天早上看到数据都导入完成，进行了整理后，用一个临时域名测试，终于是看到了故障前的数据，而且基本上没有发现损失，就切换成正式域名，把前面这上十天顶着用的缓存文件保存起来，重新生成.html.gz的缓存文件。
还有少许细节后面观察、处理，例如user_group表好像是空的，就复制一个老的数据过来，另外备份有可能还有问题，需要继续测试、观察。
以后一定要做好更仔细、更全面、更长期的备份工作，还要定期进行还原实验，确保数据无忧。周末去买了一个1T的移动硬盘，只要690元，便宜得很，与数据的价值没有办法比。
好歹这次是把数据折腾出来了，花费的时间精力无数。后面还有抓紧最近有些不顺的公司几个网站的工作，还有我那本AdSense书的出版宣传工作。如果数据还没有恢复的话，估计6月份开幕的世界杯都没有心情看啊。
| 标签：MySQL、InnoDB。 |
相关内容：
|
