内蒙古建设网站,建设工程消防备案凭证网站,保养车哪个网站做的好,在哪里能建免费的网站##状况描述突然收到MySQL报警#xff0c;从库的数据库挂了#xff0c;一直在不停的重启#xff0c;打开错误日志#xff0c;发现有张表坏了。innodb表损坏不能通过repair table 等修复myisam的命令操作。现在记录下解决过程#xff0c;下次遇到就不会这么手忙脚乱了。处理…##状况描述突然收到MySQL报警从库的数据库挂了一直在不停的重启打开错误日志发现有张表坏了。innodb表损坏不能通过repair table 等修复myisam的命令操作。现在记录下解决过程下次遇到就不会这么手忙脚乱了。处理过程一遇到报警之后直接打开错误日志里面的信息InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 30506. InnoDB: You may have to recover from a backup. 130509 20:33:48 InnoDB: Page dump in ascii and hex (16384 bytes): ##很多十六进制的代码 …… …… InnoDB: End of page dump 130509 20:37:34 InnoDB: Page checksum 1958578898, prior-to-4.0.14-form checksum 3765017239 InnoDB: stored checksum 3904709694, prior-to-4.0.14-form stored checksum 3765017239 InnoDB: Page lsn 5 614270220, low 4 bytes of lsn at page end 614270220 InnoDB: Page number (if stored to page already) 30506, InnoDB: space id (if created with MySQL-4.1.1 and stored already) 19 InnoDB: Page may be an index page where index id is 54 InnoDB: (index PRIMARY of table maitem.email_status) InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 30506. InnoDB: You may have to recover from a backup. InnoDB: It is also possible that your operating InnoDB: system has corrupted its own file cache InnoDB: and rebooting your computer removes the InnoDB: error. InnoDB: If the corrupt page is an index page InnoDB: you can also try to fix the corruption InnoDB: by dumping, dropping, and reimporting InnoDB: the corrupt table. You can use CHECK InnoDB: TABLE to scan your table for corruption. InnoDB: See also http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. InnoDB: A new raw disk partition was initialized or InnoDB: innodb_force_recovery is on: we do not allow InnoDB: database modifications by the user. Shut down InnoDB: mysqld and edit my.cnf so that newraw is replaced InnoDB: with raw, and innodb_force_... is removed. 130509 20:39:35 [Warning] Invalid (old?) table or database name #sql2-19c4-5从错误日志里面很清楚的知道哪里出现了问题该怎么处理。这时候数据库隔几s就重启所以差不多可以说你是访问不了数据库的。所以马上想到要修复innodb表了。以前在Performance的blog上看过类似文章。当时想到的是在修复之前保证数据库正常不是这么异常的无休止的重启。所以就修改了配置文件的一个参数innodb_force_recoveryinnodb_force_recovery 会影响整个InnoDB存储引擎的恢复状况。默认为0表示当需要恢复时执行所有的innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。当设置参数值大于0后可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行如主线程需要执行full purge操作会导致crash。(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志InnoDB存储引擎会将未提交的事务视为已提交。(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。因为错误日志里面提示出现了坏页导致数据库崩溃所以这里把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时操作如下执行checkrepair table 都无效alter table email_status engine myisam; #也报错了因为模式是innodb_force_recovery 1。ERROR 1025 (HY000): Error on rename of ... to .... (errno: -1)1. 建立一张表mysql create table email_status_bak #和原表结构一样只是把INNODB改成了MYISAM。2. 把数据导进去 mysql insert into email_status_bak select * from email_status;3. 删除掉原表mysql drop table email_status;4. 注释掉innodb_force_recovery 之后重启服务。5. 重命名mysql rename table edm_email_status_bak to email_status;6. 最后该回存储引擎mysql alter table edm_email_status engine innodb;总结这里的一个重要知识点就是 对 innodb_force_recovery 参数的理解了要是遇到数据损坏甚至是其他的损坏。可能上面的方法不行了需要尝试另一个方法insert into tb select * from ta limit X甚至是dump出去再load回来。
