1.中午一点的时候，机房的插座坏掉。
2.下午一点半以后陆续有人反馈网络连不上，检查发现168那台认证服务器挂了，后面继续观察，发现整个实体机挂了。
3.后面去机房，发现是插座坏了，导致几台实体机断电。
4.更换插座后服务器陆续启动
5.后面重启数据库，发现报错：
6.看到了损坏的space id，首先想到的是找到对应的数据文件，网上找到了一个小程序，可以根据ibd文件找到对应的space id，
参见：《从ibd文件获取表空间id》
7.找了一圈，没有找到对应的space id，后面发现不是ibd文件坏了 ，是undo 文件坏了，因为普通数据文件有double write机制，意外断电不会导致数据文件的异常，除非磁盘大面积损坏。
8. 网上找了个方案，就是设置参数：设置
innodb_force_
recovery ，从1 到6 逐步尝试。
1 (SRV_FORCE_IGNORE_CORRUPT): 忽略检查到的 corrupt 页。尽管检测到了损坏的 page 仍强制服务运行。一般设置为该值即可，然后 dump 出库表进行重建。 2 (SRV_FORCE_NO_BACKGROUND): 阻止主线程的运行，如主线程需要执行 full purge 操作，会导致 crash。 阻止 master thread 和任何 purge thread 运行。若 crash 发生在 purge 环节则使用该值。 3 (SRV_FORCE_NO_TRX_UNDO): 不执行事务回滚操作。 4 (SRV_FORCE_NO_IBUF_MERGE): 不执行插入缓冲的合并操作。如果可能导致崩溃则不要做这些操作。不要进行统计操作。该值可能永久损坏数据文件。若使用了该值，则将来要删除和重建辅助索引。 5 (SRV_FORCE_NO_UNDO_LOG_SCAN): 不查看重做日志，InnoDB 存储引擎会将未提交的事务视为已提交。此时 InnoDB 甚至把未完成的事务按照提交处理。该值可能永久性的损坏数据文件。 6 (SRV_FORCE_NO_LOG_REDO): 不执行前滚的操作。恢复时不做 redo log roll-forward。使数据库页处于废止状态，继而可能引起 B 树或者其他数据库结构更多的损坏。
9.打开数据库，并把read_only=1 ,置成只读模式，
10.用mysqldump 导出所有的库
11.pt-show-grants 导出所有的用户和权限。
12.删掉原来的 data目录（删之前可以先备份），并重新初始化。
13. 导入数据库
14.根据pt-show-grants导出的权限信息,新建用户并赋权。
15.有一次发现有一个数据文件ibd损坏，导致整个库都不能备份。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/82406/viewspace-2856417/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
没有了~
下一篇：
oracle数据库卡顿
请登录后发表评论
登录
全部评论
