Mysql入门MySQL数据库INNODB表损坏修复处理过程分享

Mysql入门MySQL数据库INNODB表损坏修复处理过程分享,第1张

概述介绍《Mysql入门MySQL数据库INNODB表损坏修复处理过程分享》开发教程,希望对您有用。

《MysqL入门MysqL数据库INNODB表损坏修复处理过程分享》要点:
本文介绍了MysqL入门MysqL数据库INNODB表损坏修复处理过程分享,希望对您有用。如果有疑问,可以联系我们。

MysqL学习突然收到MysqL报警,从库的数据库挂了,一直在不停的重启,打开错误日志,发现有张表坏了.innodb表损坏不能通过repair table 等修复myisam的命令 *** 作.现在记录下解决过程,下次遇到就不会这么手忙脚乱了.

MysqL学习处理过程:
 一遇到报警之后,直接打开错误日志,里面的信息:

MysqL学习InnoDB: Database page corruption on disk or a FailedInnoDB: 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 dump130509 20:37:34 InnoDB: Page checksum 1958578898,prior-to-4.0.14-form checksum 3765017239InnoDB: stored checksum 3904709694,prior-to-4.0.14-form stored checksum 3765017239InnoDB: Page lsn 5 614270220,low 4 bytes of lsn at page end 614270220InnoDB: Page number (if stored to page already) 30506,InnoDB: space ID (if created with >= MysqL-4.1.1 and stored already) 19InnoDB: Page may be an index page where index ID is 54InnoDB: (index "PRIMARY" of table "maitem"."email_status")InnoDB: Database page corruption on disk or a FailedInnoDB: file read of page 30506.InnoDB: You may have to recover from a backup.InnoDB: It is also possible that your operatingInnoDB: system has corrupted its own file cacheInnoDB: and rebooting your computer removes theInnoDB: error.InnoDB: If the corrupt page is an index pageInnoDB: you can also try to fix the corruptionInnoDB: by dumPing,dropPing,and reimportingInnoDB: the corrupt table. You can use CHECKInnoDB: table to scan your table for corruption.InnoDB: See also http://dev.MysqL.com/doc/refman/5.5/en/forcing-innodb-recovery.HTMLInnoDB: about forcing recovery.InnoDB: A new raw disk partition was initialized orInnoDB: innodb_force_recovery is on: we do not allowInnoDB: database modifications by the user. Shut downInnoDB: MysqLd and edit my.cnf so that newraw is replacedInnoDB: with raw,and innodb_force_... is removed.130509 20:39:35 [Warning] InvalID (old?) table or database name '#sql2-19c4-5'

MysqL学习从错误日志里面很清楚的知道哪里出现了问题,该怎么处理.这时候数据库隔几s就重启,所以差不多可以说你是访问不了数据库的.所以马上想到要修复innodb表了.
以前在Performance的blog上看过类似文章.

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

MysqL学习innodb_force_recovery影响整个InnoDB存储引擎的恢复状况.默认为0,表示当需要恢复时执行所有的innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响.当设置参数值大于0后,可以对表进行select,create,drop *** 作,但insert,update或者delete这类 *** 作是不允许的.1(SRV_FORCE_IGnorE_CORRUPT):忽略检查到的corrupt页.2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行,如主线程需要执行full purge *** 作,会导致crash.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):不执行前滚的 *** 作.

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

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

MysqL学习 *** 作步骤:
因为被破坏的地方只在索引的部分,所以当使用innodb_force_recovery = 1运行InnoDB时, *** 作如下:

MysqL学习执行check,repair table 都无效alter table email_status engine =myisam; #也报错了,因为模式是innodb_force_recovery =1.ERROR 1025 (HY000): Error on rename of '...' to '....' (errno: -1)
MysqL学习建立一张表: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

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

总结

以上是内存溢出为你收集整理的Mysql入门MySQL数据库INNODB表损坏修复处理过程分享全部内容,希望文章能够帮你解决Mysql入门MySQL数据库INNODB表损坏修复处理过程分享所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/1163928.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-06-01
下一篇 2022-06-01

发表评论

登录后才能评论

评论列表(0条)

保存