MySQL数据库引擎表损坏修复处理过程

类型：数据库类大小：1.7M语言：英文评分：6.6标签:立即下载突然收到关系型数据库报警，从库的数据库挂了，一直在不停的重启，打开错误日志，发现有张表坏了innodb。表损坏不能通过修理台等修复引擎的命令操作。现在记录下解决过程，下次遇到就不会这么手忙脚乱了。

处理过程：一遇到报警之后，直接打开错误日志，里面的信息：

InnoDB:磁盘上的数据库页面损坏或读取30506页的失败noDB:文件。您可能需要从备份中恢复。##很多十六进制的代码……InnoDB:页面转储结束130509 20:37:34 innodb :页面校验和1958578898,4.0.14之前格式的校验和3765017239InnoDB:存储的校验和3904709694,4.0.14之前格式的存储的校验和3765017239 innodb 333694 email _ status ')innodb :磁盘上的数据库页面损坏或读取30506页的失败noDB:文件InnoDB:您可能需要从备份中恢复InnoDB:也有可能是您的operatingInnoDB:系统损坏了自己的文件缓存InnoDB:重新启动计算机会消除InnoDB:错误InnoDB:如果损坏的页是索引页InnoDB:您也可以尝试通过转储、删除和重新导入损坏的表来修复损坏的InnoDB:您可以使用CHECKInnoDB:表格来扫描您的表是否损坏InnoDB:另请参阅http://dev。MySQL。com/doc/ref man/5.5/en/forcing-innodb-recovery。html innodb :关于强制恢复InnoDB:一个新的原始磁盘分区已初始化或noDB: innodb_force_recovery为：我们不允许用户修改数据库。关闭downInnoDB: mysqld并编辑我的. cnf，以便用生的替换纽劳，并用innodb _ force _.被移除。130509 20:39:35[警告]无效（旧？)表或数据库名称#sql2-19c4-5 '从错误日志里面很清楚的知道哪里出现了问题，该怎么处理。这时候数据库隔几s就重启，所以差不多可以说你是访问不了数据库的。所以马上想到要修复引擎表了。以前在表演的博客上看过类似文章。

当时想到的是在修复之前保证数据库正常，不是这么异常的无休止的重启。所以就修改了配置文件的一个参数：innodb_force_recovery

innodb_force_recovery影响整个InnoDB存储引擎的恢复状况。默认为0,表示当需要恢复时执行所有的innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。当设置参数值大于0后，可以对表进行选择、创建、删除操作，但插入，更新或者删除这类操作是不允许的1(SRV _ FORce _ IGNORE _ CORPORTT):忽略检查到的腐败的页2(SRV _ FORCE _ NO _ BACKGROUND):阻止主线程的运行，如主线程需要执行完全净化操作，会导致撞车事故. 3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作4(SRV _ Force _ NO _ IBUF _ MERGE):不执行插入缓冲的合并操作5(SRV _ FORCE _ NO _ UNDO _ LOG _ SCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。因为错误日志里面提示出现了坏页，导致数据库崩溃，所以这里把innodb_force_recovery设置为1,忽略检查到的坏页。重启数据库之后，正常了，没有出现上面的错误信息。找到错误信息出现的表：(表"梅特姆"的索引“PRIMARY”.)电子邮件_状态)

数据页的聚集键索引已损坏。与损坏的数据二级索引相比，这种情况要糟糕得多，因为后者可以使用OPTIMIZE TABLE命令修复，但比更难恢复的损坏的表字典要好。

操作步骤：由于损坏的地方只在索引部分，当InnoDB运行innodb_force_recovery=1时，操作如下：

检查和修复表无效。alter table email _ status engine=my isam；#还报告了一个错误，因为模式是innodb_force_recovery=1。重命名“.”时出现错误1025 (hy000) :错误去……(errno :-1)创建表：创建表email_status_bak #的结构与原始表相同，只是INNODB更改为MYISAM。将数据导入到“插入到电子邮件_状态_ bak”中，然后从“电子邮件_状态”中选择*；删除原表：删除表email _ status注释掉innodb_force_recovery并重新启动。将表EDM _ email _ status _ bak重命名为email _ status；最后，存储引擎更改表EDM _ email _ status engine=innodb总结：这里重要的知识点之一就是对innodb_force_recovery参数的理解，如果有数据损坏甚至其他损坏。也许上面的方法行不通，你需要尝试另一种方法：插入到TB中从ta限制x中选择*即可；甚至倒出来装回去。