Mysql异常停止之后的恢复操作

你好，我是本际云服务器推荐网的小编小本本。今天，我想和大家分享一下Mysql异常停止之后的恢复操作。

Mysql异常停止之后的恢复操作

操作过程

之前，测试环境主机出现了登陆不上的情况。发现是现场断电，导致虚拟机所在的物理机关机了。这样的话虚拟机上跑的一些进程没有手动停止就异常关闭了，可能会出现问题。等物理机开机登陆之后，发现mysql启动失败了。接下来，记录下了解决该问题的操作方式。

1. 直接启动mysql报错

经过排查，发现该问题有多种可能原因：

可能是/xxx/xxxx/xxxx/mysqld.pid文件没有写的权限。
可能进程里已经存在mysql进程。
可能是第二次安装mysql未删除之前环境的mysql-bin.index，从而影响服务启动。
my.cnf配置文件下，未指定datadir。
my.cnf配置文件下skip-federated没有被注释。
mysql启动目录的所属者和所属组不对。
没关闭selinux。

核查后，以上情况均未造成问题。

2. 在my.cnf中加innodb_force_recovery=x参数

该参数可以设置值1-6，直到库能启动为止。

1) (SRV_FORCE_IGNORE_CORRUPT): 忽略检查到的corrupt页。尽管检测到了损坏的page仍强制服务运行。一般设置为该值即可，然后dump出库表进行重建。
2) (SRV_FORCE_NO_BACKGROUND): 阻止主线程的运行，如主线程需要执行fullpurge操作，会导致crash。阻止masterthread和任何purgethread运行。若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): 不执行前滚的操作。恢复时不做redologroll-forward。使数据库页处于废止状态，继而可能引起B树或者其他数据库结构更多的损坏。

在本次恢复操作中，只有设置为6才将库启动成功。

3. 启动之后查看mysql日志，发现库可能已经损坏

只能选择将库的数据全量导出，mv掉data目录之后再重新初始化。注意：因为log_detail表已经损坏，无法正常查看导出，只能跳过改存储日志的表，导出表结构，后续在重新创建此表。Mv掉原存储数据的data目录，并且重新创建data目录：配置my.cnf将my.cnf中innodb_force_recovery这行配置删除或者配置为innodb_force_recovery=0,初始化mysql。