利用 Forcing InnoDB Recovery 特性解决 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 页。尽管检测到了损坏的 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 树或者其他数据库结构更多的损坏。
注意：
为了安全，当设置参数值大于 0 后，可以对表进行 select, create, drop 操作,但 insert, update 或者 delete 这类操作是不允许的。MySQL 5.6.15 以后，当 innodb_force_recovery 的值大于等于 4 的时候，InnoDB 表处于只读模式。
在值小于等于 3 时可以通过 select 来 dump 表，可以 drop 或者 create 表。MySQL 5.6.27 后大于 3 的值也支持 DROP TABLE；
如果事先知道哪个表导致了崩溃则可 drop 掉这个表。如果碰到了由失败的大规模导入或大量 ALTER TABLE 操作引起的 runaway rollback，则可 kill 掉 mysqld 线程然后设置 innodb_force_recovery = 3 使数据库重启后不进行 rollback。然后删除导致 runaway rollback 的表；
如果表内的数据损坏导致不能 dump 整个表内容。那么附带 order by primary_key desc 从句的查询或许能够 dump 出损坏部分之后的部分数据；
若使用更高的 innodb_force_recovery 值，那么一些损坏的数据结构可能引起复杂的查询无法运行。此时可能只能运行最基本的 select * from table 语句。
解决
前面说了，表空间损坏，重启时前滚恢复失败，因此在重启的时候不要执行前滚的操作，在 /etc/mysql/my.cnf 中添加：
[mysqld]
innodb_force_recovery = 6
然后重启 MySQL，立即对数据库用 mysqldump 把数据导出。完成后，去掉 innodb_force_recovery 或者设置为 0，然后重新创建数据库，把数据导入。
最后
这个方法仅仅是紧急情况下的一种补救，不能依赖于这个办法，最好是做好数据备份工作，包括全备份和日志备份。确定要使用该方案是要确保有原始损坏数据的副本。4 以上的值可能永久导致数据文件损坏。务必在测试环境测试通过后再在生产环境使用。
MySQL crash 或者 MySQL 服务器 crash 会导致各种各种的问题 ，对于主从复制关系，MySQL 5.6 版本开始新增了 crash-safe 的特性，可以在最大程度上避免 error 1594 的问题，保证数据的安全，如何开启这个功能可以参考上一篇博文：MySQL 5.6 从库开启 crash-safe 功能。
作为一个 DBA，遇到问题，要淡定，细心阅读日志，从中找的相关错误提示，然后依据错误找到相关的解决方法来解决问题。
