利用 force recovery 解决服务器 crash 导致 MySQL 重启失败的问题

小明同学在本机上安装了 MySQL 5.7.17 配合项目进行开发，并且已经有了一部分重要数据。某天小明在开发的时候，需要出去一趟就直接把电脑关掉了，没有让 MySQL 正常关闭，重启 MySQL 的时候，报错如下：

...
[ERROR] InnoDB: Space id and page no stored in the page, read in are [page id: space=3611051955, page number=1571966525], should be [page id: space=86, page number=4]
...
[ERROR] InnoDB: Database page corruption on disk or a failed file read of page [page id: space=86, page number=4]. You may have to recover from a backup.
...
[ERROR] [FATAL] InnoDB: Aborting because of a corrupt database page in the system tablespace. Or,  there was a failure in tagging the tablespace  as corrupt.
...

从日志内容来看，MySQL 在机器关机的时候有数据没有落地，导致日志文件损坏，重启之后无法正常恢复，线程在数据页中读取不到需要的 page 和数据。

因为日志文件已经损坏，需要做特殊操作，让 MySQL 跳过恢复，启动 MySQL，然后把数据导出来，再重建数据库导入。

MySQL 有个一个特性：Forcing InnoDB Recovery，启用这个特性需要设置 innodb_force_recovery 大于 0。

innodb_force_recovery 可以设置为 1-6，大的数字包含前面所有数字的影响。

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): 不执行前滚的操作。

注意：
为了安全，当设置参数值大于 0 后，可以对表进行 select, create, drop 操作,但 insert, update 或者 delete 这类操作是不允许的，当 innodb_force_recovery 的值大于等于 4 的时候，InnoDB 表处于只读模式。

前面说了，日志数据不一致，重启时前滚恢复失败，因此在重启的时候不要执行前滚的操作，在 /etc/mysql/my.cnf 中添加：

innodb_force_recovery=6

然后重启 MySQL，立即对数据库用 mysqldump 把数据导出。完成后，去掉 innodb_force_recovery 或者设置为 0，然后重新创建数据库，把数据导入。

MySQL crash 或者 MySQL 服务器 crash 会导致各种各种的问题 ，但 MySQL 5.6 版本开始怎增了 crash-safe 的特性，可以在最大程度上避免 error 1594 的问题，如何开启这个功能可以参考上一篇博文：MySQL 5.6 从库开启 crash-safe 功能，遇到问题，要淡定，细心阅读日志，从中找的相关错误提示，然后依据错误找到相关的解决方法来解决问题。