MYSQL数据表损坏的分析
MYSQL 数据表损坏的分析＜1.0＞作 者： 王黎晓 完成日期： -12-20 修改情况记录：版本号 修改人 修改日期 审核人 批准人 备注1.0-draft 王黎晓 -12-20 创建增加检查办法我们运行一个 cron 任务，每小时检查我们所有重要的表，在 FC5“crontab”文件中使用这样的行：1 * * * * /usr/bin/myisamchk -s /var/lib/mysql/cef_push/*.MYI > /var/sync/log/mysql-check.log文档编号：在 solaris 9“crontab”文件中使用这样的行：1 * * * * /usr/local/mysql/bin/myisamchk -s /usr/local/mysql/var/cef_push /*.MYI > /var/sync/log/mysql-check.log这打印出损坏的表的信息，因此我们能检验并且在需要时修复他们。崩溃恢复停掉 mysql，再检查。一张损坏的表的症状通常是查询意外中断并且你能看到例如这些错误： “tbl_name.frm”被锁定不能改变。 不能找到文件“tbl_name.MYI”(Errcode ：### )。 从表处理器的得到错误###(此时，错误 135 是一个例外)。 意外的文件结束。 记录文件被毁坏。 在这些情况下，你必须修复表。myisamchk 通常能检测并且修复出错的大部分东西。修复过程包含最多 4 个阶段，在下面描述。在你开始前，你应该 cd 到数据库目录和检查表文件的权限，确保他们可被运行 mysqld 的 Unix 用户读取(和你，因为你需要存取你正在检查的文件)。如果它拒绝你修改文件，他们也必须是可被你写入的。阶段 1：检查你的表 运行 myisamchk *.MYI 或(myisamchk -e *.MYI，如果你有更多的时间)。使用-s(沉默)选项禁止不必要的信息。你必须只修复那些 myisamchk 报告有一个错误的表。对这样的表，继续到阶段2。 如果在检查时，你得到奇怪的错误(例如 out of memory 错误)，或如果myisamchk 崩溃，到阶段 3。舞台 2 ：简单安全的修复 首先，试试 myisamchk -r -q tbl_name(-r -q 意味着“快速恢复模式”)。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切和在数据文件指向正确地点的删除连接，这应该管用并且表可被修复。开始修理下一张表。否则，使用下列过程： 1. 在继续前做数据文件的一个备份。 2. 使用 myisamchk -r tbl_name(-r 意味着“恢复模式”)。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。 3. 如果前面的步骤失败，使用 myisamchk --safe-recover tbl_name。安全恢复模式使用一个老的恢复方法，处理常规恢复模式不行的少数情况(但是更慢)。 如果在修复时，你得到奇怪的错误(例如 out of memory 错误)，或如果myisamchk 崩溃，到阶段 3。舞台 3 ：困难的修理 如果在索引文件的第一个 16K 块被破坏，或包含不正确的信息，或如果索引文件丢失，你只应该到这个阶段 。在这种情况下，创建一个新的索引文件是必要的。按如下这样做： 1. 把数据文件移更安全的地方。 2. 使用表描述文件创建新的(空)数据和索引文件：3. shell> mysql db_name4. mysql> DELETE FROM tbl_name;5. mysql> quit6. 将老的数据文件拷贝到新创建的数据文件之中。(不要只是将老文件移回新文件之中；你要保留一个副本以防某些东西出错。) 回到阶段 2。现在 myisamchk -r -q 应该工作了。(这不应该是一个无限循环)。阶段 4：非常困难的修复 只有描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。 1. 从一个备份恢复描述文件并且回到阶段 3。你也可以恢复索引文件并且回到阶段 2。对后者，你应该用 myisamchk -r 启动。 2. 如果你没有一个备份但是确切地知道表是怎样被创建的，在另一个数据库中创建表的一个拷贝。删除新的数据文件，然后从其他数据库将描述和索引文件移到破坏的数据库中。这给了你新的描述和索引文件，但是让数据文件独自留下来了。回到阶段 2 并且尝试重建索引文件。 参考资料 《MySQL 中文参考手册-维护 MySQL 安装》
