硬盘出问题後MySql的修复

hmilycbz

   上上周公司的一台服务器硬盘出毛病了，导致不能访问该服务，当时也没在意，因为这台服务器毛病特多，所以就让IDC给重启了，结果问题就。。。。。。
   重启后发现对应的服务中有一个表的数据少了2/3，从去年5月份到今年3月份中间的数据全没了，天啊，当时汗就冒出来了，这下死定了，当时备份的数据也只到今年2月份，这样还是少了1个月的数据啊，主要问题还不在这，由于数据的丢失导致用户对我们服务的信心的缺失那才是最要命的。
   无论如何也得把这数据给找回来，首先把服务给停掉，避免用户写入数据，然后使用repair table，结果依旧，使用myisamchk进行检查，均没有发现任何问题，到mysql数据库目录中进行查看，看到一个很莫名其妙的比较大的文件：
   fee-070409144408.BAK
前面的fee与那个丢失数据的表名一样，后面的刚好是重启服务器的时间，难道是系统已经发现了错误而自动做的一个备份，可是这是一个什么文件呢？只由bak的后缀名是无法判断具体备份的是什么样的数据。
   先新建一个表feetest，然后尝试着使用mysql命令进行导入，结果出错，看来这办法行不通
   通过对比发现该文件的格式与.MYD格式差不多，是不是就是MYD文件呢？尝试将fee-070409144408.BAK文件更改成新建的表feetest中的feetest.MYD文件，进入mysql，发现入法进入feetest表了，退出，使用myisamchk进行检查，结果由fee-070409144408.BAK文件变得很小，比原来的都还小，想想可能是由于myisamchk进行的检查还是基于索引而来的，我们的这个索引文件本来已经被破坏了
   没办法，只好进行google，可是没有找到任何资料
   郁闷了。。。。。。
   静下心来仔细想想，觉得看看有没有办法进行MYD文件的修复呢？找了mysql的手册，发现有这样的一个东西：
REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE    tbl_name [, tbl_name] ... [QUICK] [EXTENDED] [USE_FRM]
REPAIR TABLE用于修复被破坏的表。默认情况下，REPAIR TABLE与myisamchk --recover tbl_name具有相同的效果。
对于每个被修复的表，REPAIR TABLE语句会产生多行的信息。上一行含有一个Msg_type状态值。Msg_test通常应为OK。如果您没有得到OK，您应该尝试使用myisamchk --safe-recover修复表，因为REPAIR TABLE尚不会执行所有的myisamchk选项。我们计划在将来使它的灵活性更强。
如果给定了QUICK，则REPAIR TABLE会尝试只修复索引树。这种类型的修复与使用myisamchk --recover --quick相似。
如果您使用EXTENDED，则MySQL会一行一行地创建索引行，代替使用分类一次创建一个索引。这种类型的修复与使用myisamchk --safe-recover相似。
对于REPAIR TABLE，还有一种USE_FRM模式可以利用。如果.MYI索引文件缺失或标题被破坏，则使用此模式。在这种模式下，MySQL可以使用来自.frm文件重新创建.MYI文件。这种修复不能使用myisamchk来完成。 注释：只能在您不能使用常规REPAIR模式是，才能使用此模式。.MYI标题包含重要的表元数据（特别是，当前的AUTO_INCREMENT值和Delete链接）。这些元数据在REPAIR...USE_FRM中丢失。如果表被压缩，则不能使用USE_FRM。因为本信息也存储在.MYI文件中。
我的这种情况也是缺少索引，能不能这样进行修复呢？
管它呢，死马当活马医，先试试再说：
1、drop掉feetest表
2、新建一个表feetest，表结构与fee表一致
3、用fee-070409144408.BAK替换掉feetest.MYD
4、进入mysql中运行：
   mysql> REPAIR TABLE feetest EXTENDED USE_FRM;
5、经过漫长的等待之后出现了如下的字符：
+-------------+--------+---------+------------------------------------------------+
| Table       | Op     | Msg_type| Msg_text                                       |
+-------------+--------+---------+------------------------------------------------+
| acc.feetest | repair | info    | Wrong bytesec:   0-  0-  0 at 8910208; Skipped |
| acc.feetest | repair | warning | Number of rows changed from 0 to 183083        |
| acc.feetest | repair | status  | OK                                             |
+-------------+--------+---------+------------------------------------------------+
3 rows in set (20 min 12.26 sec)
看到了Number of rows changed from 0 to 183083，然后查看原表中的数据ID字段（由于是中间部分数据缺失，所以最后的ID还是会保留），发现ID字段最后一个的值是183083，哈哈，看来是有希望的了，那个心情真是无法用语言来表达。然后导出这个表，导入到fee中，启动服务，一切正常。

弄到了晚上2点多，终于回去可以睡个好觉了。

不过经过这样一件事之后，使得我对数据库的备份之重要性提高了警觉。

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/23834/showart_284516.html