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

突然收到MySQL报警，从库的数据库挂了，一直在不停的重启，打开错误日志，发现有张表坏了。innodb表损坏不能通过repair table 等修复myisam的命令操作。现在记录下解决过程

 

 

当innodb表空间损坏时候，尝试启动数据库不成功，可以使用innodb_force_recovery参数进行强制启动

在主配置文件my.cnf中添加
innodb_force_recovery=6

 

因为错误日志里面提示出现了坏页，导致数据库崩溃，所以这里把innodb_force_recovery 设置为1，忽略检查到的坏页。重启数据库之后，正常了，没有出现上面的错误信息。找到错误信息出现的表： (index "PRIMARY" of table "maitem"."email_status")

数据页面的主键索引(clustered key index)被损坏。这种情况和数据的二级索引(secondary indexes)被损坏相比要糟很多，因为后者可以通过使用OPTIMIZE TABLE命令来修复，但这和更难以恢复的表格目录(table dictionary)被破坏的情况来说要好一些。

操作步骤： 因为被破坏的地方只在索引的部分，所以当使用innodb_force_recovery = 1运行InnoDB时，操作如下：

执行check，repair table 都无效
alter table email_status engine =myisam; #也报错了，因为模式是innodb_force_recovery =1。
ERROR 1025 (HY000): Error on rename of '...' to '....' (errno: -1)

建立一张表：
create table email_status_bak  #和原表结构一样，只是把INNODB改成了MYISAM。

把数据导进去
insert into email_status_bak select * from email_status;

删除掉原表：
drop table email_status;

注释掉innodb_force_recovery 之后，重启。
重命名：
rename table edm_email_status_bak to email_status;

最后该回存储引擎
alter table edm_email_status engine = innodb

总结： 这里的一个重要知识点就是 对 innodb_force_recovery 参数的理解了，要是遇到数据损坏甚至是其他的损坏。可能上面的方法不行了，需要尝试另一个方法：insert into tb select * from ta limit X；甚至是dump出去，再load回来。