InnoDB Forcing Recovery

官方文档：
https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html

若要调查数据库页损坏，可以使用SELECT从数据库转储表。。。进入外岛。通常，用这种方法获得的大多数数据是完整的。严重损坏可能导致SELECT*FROM tbl_name语句或InnoDB后台操作崩溃或断言，甚至导致InnoDB前滚恢复崩溃。在这种情况下，可以使用innodb_force_recovery选项在阻止后台操作运行的同时强制启动innodb存储引擎，以便转储表。例如，在重新启动服务器之前，可以将以下行添加到选项文件的[mysqld]部分：

[mysqld]
innodb_force_recovery = 1

警告：
只有在紧急情况下将innodb_force_recovery设置为大于0的值，这样您才能启动innodb并转储表。在执行此操作之前，请确保您有数据库的备份副本，以防需要重新创建它。值为4或更大可能会永久损坏数据文件。只有在成功地在数据库的单独物理副本上测试了innodb_force_recovery设置后，才能在生产服务器实例上使用该设置4或更高。当强制执行InnoDB recovery时，您应该始终从InnoDB_force_recovery=1开始，并且只在必要时递增该值。


innodb_force_recovery默认为0（正常启动，不强制恢复）。innodb_force_recovery的允许非零值为1到6。较大的值包括较小值的功能。例如，值3包括值1和2的所有功能。
如果您能够转储innodb force_recovery值小于等于3的表，那么您就相对安全了，只有损坏的单个页面上的一些数据会丢失。值为4或更大被认为是危险的，因为数据文件可能会永久损坏。值6被认为是极端的，因为数据库页处于过时状态，这反过来可能会导致B树和其他数据库结构的损坏。
作为安全措施，当InnoDB force_recovery大于0时，InnoDB会阻止插入、更新或删除操作。innodb_force_recovery设置为只读模式下的4个或更多位置innodb。


1（SRV_FORCE_IGNORE_CORRUPT）
允许服务器运行，即使它检测到损坏的页。尝试使SELECT*FROM tbl_name跳过损坏的索引记录和页，这有助于转储表。

2（SRV_FORCE_NO_背景）
防止主线程和任何清除线程运行。如果清除操作期间发生崩溃，则此恢复值将阻止崩溃。

3（SRV_FORCE_NO_TRX_UNDO）
在崩溃恢复后不运行事务回滚。

4（SRV_FORCE_NO_IBUF_MERGE）
防止插入缓冲区合并操作。如果他们会导致撞车，不要这样做。不计算表统计信息。此值可能会永久损坏数据文件。使用此值后，请准备删除并重新创建所有辅助索引。将InnoDB设置为只读。

5（SRV_FORCE_NO_UNDO_LOG_扫描）
启动数据库时不查看撤消日志：InnoDB甚至将不完整的事务视为已提交。此值可能会永久损坏数据文件。将InnoDB设置为只读。

6（SRV_FORCE_NO_LOG_重做）
不执行与恢复相关的重做日志前滚。此值可能会永久损坏数据文件。使数据库页处于过时状态，这反过来又可能导致B树和其他数据库结构的损坏。将InnoDB设置为只读。


您可以从表中选择来转储它们。如果innodb_force_recovery值小于等于3，则可以删除或创建表。DROP TABLE还支持innodb_force_recovery值大于3，直到MySQL 5.7.17。从MySQL 5.7.18开始，当innodb_force_recovery值大于4时，不允许使用DROP TABLE。
如果您知道给定的表在回滚时导致崩溃，则可以删除它。如果遇到由于大容量导入或ALTER TABLE失败而导致的失控回滚，可以终止mysqld进程，并将innodb_force_recovery设置为3以在不进行回滚的情况下启动数据库，然后删除导致失控回滚的表。
如果表数据中的损坏阻止您转储整个表内容，则使用ORDER BY primary_key DESC子句的查询可能能够在损坏的部分之后转储表的部分。
如果启动innodb需要较高的innodb force_recovery值，则可能存在损坏的数据结构，从而导致复杂查询（包含WHERE、ORDER BY或其他子句的查询）失败。在这种情况下，您可能只能运行基本的SELECT*FROM t查询。