Mysql异常停止之后的恢复操作
点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！有次测试环境主机登陆不上，之后发现是现场断电，导致虚拟机所在的物理机关机了。这样的话虚拟机上跑的一些进程没有手动停止就异常关闭了，可能会出现问题。等物理机开机登陆之后，看环境状态，果然mysql启动失败了，在此记录下此情况的解决方式。
上网查看了一下报错，主要有以下几种可能导致报错的情况：
- 1)可能是/xxx/xxxx/xxxx/mysqld.pid文件没有写的权限。
- 3)可能是第二次在机器上安装mysql，之前环境的mysql-bin.index没删除影响了服务的启动。
- 4)my.cnf配置文件下，没有指定datadir。
- 5)my.cnf配置文件下skip-federated没有被注释。
2.2 在my.cnf中加innodb_force_recovery=x参数，值填写从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 树或者其他数据库结构更多的损坏。
2.3 启动之后查看mysql日志，发现库可能已经损坏2.4 只能选择将库的数据全量导出，mv掉data目录之后再重新初始化注意：因为log_detail表已经损坏，无法正常查看导出，只能跳过改存储日志的表，导出表结构，后续在重新创建此表。Mv掉原存储数据的data目录，并且重新创建data目录：配置my.cnf 将my.cnf中innodb_force_recovery 这行配置删除或者配置为innodb_force_recovery=0,初始化mysql。2.6 重新导入之前备份的数据，并根据之前损坏表的表结构创建之前过滤掉的表2.7 核查下导入数据是否正常，若无问题，只能用这样的办法解决异常停止导致的启动失败了，否则直接删掉ib_logfile0，ib_logfile1，可以将库拉起，但是库还是损坏状态。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/129120.html
