笨猪一条 | A foolman, a foolpig

上上周公司的一台服务器硬盘出毛病了，导致不能访问该服务，当时也没在意，因为这台服务器毛病特多，所以就让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点多，终于回去可以睡个好觉了。

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

本文地址 : http://www.foolpig.com/2008/02/14/%e7%a1%ac%e7%9b%98%e5%87%ba%e9%97%ae%e9%a2%98%e5%be%8cmysql%e7%9a%84%e4%bf%ae%e5%a4%8d/
如果你对本文感兴趣，欢迎订阅我的博客