mysql不完全恢复之innodb_force_recovery参数

　　上上周，一产品的TL钉钉我，说一生产环境mysql停了后起不来了，让我帮忙看能不能解决下。

　　远程过去后，看日志如下：

　　ERROR 1812 (HY000): Tablespace is missing for table `test2`.`test`.

　　遂先确认是不是库已经备份了，是不是完全不能丢失数据。客户表示尽量不丢，实在不行少量也能接受。该业务tps不高、大型事务也不多，于是将innodb_force_recovery设置为6，让库正常起来。起来后，客户就开始导出备份了。

关于参数innodb_force_recovery

　　和oracle resetlogs一样的作用。参数innodb_force_recovery影响了整个Innodb存储引擎的恢复状况。该值默认为0，表示当需要恢复时执行所有的恢复操作。当不能进行有效恢复时，如数据页发生了corruption，Mysql数据库可能会宕机，并把错误写入错误日志中。

        但在某些情况下，可能不需要执行完整的恢复操作。例如在进行alter table操作时，这时发生意外，数据库重启时会对Innodb表执行回滚操作。对于一个大表，这需要很长时间，甚至可能是几个小时。这时可以自行恢复，例如将表删除，从备份中重新将数据导入表中，这些操作可能要快于回滚操作。

       Innodb_force_recovery可以设置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):不执行前滚的操作。

     备注：当设置innodb_force_recovery大于0后，可以对表进行select、create、drop操作，但insert、update或者delete这类操作是不允许的。

　　注：对于mysql，非常不建议跑在虚拟机环境中，根据LZ的印象，处理过的十几起mysql损坏的情况都是虚拟机环境的。

　　如果有备份表，先考虑拷贝备份文件尝试启动。参见https://www.cnblogs.com/zhjh256/p/6065104.html。