MySQL崩溃-修复损坏的innodb：innodb_force_recovery

Windows上安装了XMAPP-controller之后间歇性出现MySQL无法启动，查看日之后发现是innodb的报错，报错信息如下：

度娘上各种答案无法解决，后来直接看官方文档，直接上解决方案：

踩坑指南 - - *** 作配置前需要做这些 *** 作：

1、配置my.cnf 配置innodb_force_recovery = 1 到 6 试到正确为止，重启MySQL

2、导出数据脚本 mysqldump -uroot -p123456 test >test.sql 导出SQL脚本。或者用Navicat将所有数据库/表导入到其他服务器的数据库中。 注意：这里的数据一定要备份成功。然后删除原数据库中的数据。

3、删除ib_logfile0、ib_logfile1、ibdata1 备份MySQL数据目录下的ib_logfile0、ib_logfile1、ibdata1三个文件，然后将这三个文件删除

4、配置my.cnf 将my.cnf中innodb_force_recovery 这行配置删除或者配置为innodb_force_recovery = 0，重启MySQL服务

5、将数据导入MySQL数据库 mysql -uroot -p123456 test <test.sql

或者用Navicat将备份的数据导入到数据库中。 如果在导入数据过程中发生tablespace不存在的问题，请删除data目录相应database下的文件。

故障处理

移除当前使用的 redo log 文件，然后可以试着启动数据库，结果启动失败！

提示：

[ERROR] InnoDB: Page [page id: space=0, page number=0] log sequence number 178377412422 is in the future! Current system log sequence number 165909011496.

这样的错误，这是因为 MySQL writer 线程按照配置的时间间隔以 page 为单位刷新 buffer 数据到磁盘。当数据刷新到磁盘的时候，新写入磁盘的 page 包含了较新的 LSN，此时系统 system 表空间头的 LSN 并没有同步更新，通常这是检查点线程的工作。在正常的崩溃恢复中，MySQL 可以借助 redo log 来进行前滚和回滚，但是此时 redo log 已经被我们删掉了，MySQL 无法进行恢复 *** 作。此时，我们设置 innodb_force_recovery=3 来强制启动 MySQL，仍然启动不成功，改成 4 后启动了！

再使用 mysqldump 导出备份，结果噩梦又降临了！MySQL 又 crash 了。

提示：

InnDB: Failed to find tablespace for table......

设置参数 innodb_force_recovery=5，数据库仍然启动失败，再设置成 6，启动成功！用 sqldump 顺利把数据备份出来了！

再初始化数据库，把刚刚备份的数据库导入，数据库恢复成功完成！

参数说明

这里的关键是设置 innodb_force_recovery 参数，对应这个参数的说明如下：

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数据库

无法启动怎么备份

要看不能启动的具体原因，如果是程序部分异常，那么数据是好的，可以打包备份。相反，如果是数据出了问题导致无法启动，备份了也不是完整的。

MYSQL的所有数据库的数据是以文件形式保存在文件夹里面的，例如c:\mysql\data文件夹，直接打包此文件夹下的所有文件就可以达到备份的目的。

---