MySQL错误Got error -1 from storage engine

前言

之前正式服务器数据库挂掉了，被其他同事覆盖数据库，导致正在使用的数据库无法访问，并且所有配置全部丢失，幸好data数据存储在其他路径免受劫难。
在恢复之前，为避免有人往实例里写入内容，所以在my.cnf/my.ini（Linux=my.cnf，Windows=my.ini）内添加了innodb_force_recovery=4

正文

innodb_force_recovery影响整个innodb存储引擎的恢复状况

说明

在未配置属性innodb_force_recovery时，它默认值是0（表示可执行所有），并且不存在于my.cnf/my.ini内。
innodb_force_recovery的参数值可以为0-6，当其大于0时，可以对表进行select、create、drop操作，但insert、update、delete是不允许的。并且重要的一点是，当设置为大于0后，以下条目是包含状态：
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):不执行前滚的操作。

附加

innodb_purge_threads 

该参数用于定义处理innodb的清除操作模式，默认的是定期回收无用数据的操作。在之前的几个版本中，清除操作是主线程的一部分，这意味着运行时它可能会堵塞其它的数据库操作。
从MySQL5.5.X版本开始，该操作运行于独立的线程中,并支持更多的并发数。用户可通过设置innodb_purge_threads配置参数来选择清除操作是否使用单独线程。
默认为0，即不启用。设置为 1 时表示使用单独的清除线程。

楼主因为设置过innodb_purge_threads=1，然后又在进行上面操作时更改了innodb_force_recovery=4，之后导致出现无限loop情况。
查询原因发现，mysql源码控制了这2个参数的设置，如果同时启用，则一直挂起在循环内，所以在开启innodb_force_recovery时，注意将innodb_purge_threads=0.