【案例】利用innodb_force_recovery 解决MySQL服务器crash无法重启问题

一 背景
   某一创业的朋友的主机因为磁盘阵列损坏机器crash,重启MySQL服务时 报如下错误:
二 分析
    主要关注 mysqld got signal 11 的问题,从日志内容分析来看,数据库在机器crash 导致日志文件损坏,重启之后无法正常恢复,更无法正常对外提供服务。

三 解决
    因为日志已经损坏，这里采用非常规手段,首先修改innodb_force_recovery参数，使mysqld跳过恢复步骤，将mysqld 启动,将数据导出来然后重建数据库。
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):不执行前滚的操作。
注意 
  a 当设置参数值大于0后，可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。
  b 当innodb_purge_threads 和 innodb_force_recovery一起设置会出现一种loop现象:   

在my.cnf中修改以下两个参数
innodb_force_recovery=6
innodb_purge_thread=0

重启MySQL 

立即对数据库做逻辑导出 ，完成之后将innodb_force_recovery设置为0 ，innodb_purge_thread=1 , 然后重建数据库 。
另外 MySQL 版本 5.5以及之前 ,当innodb_purge_threads =1，innodb_force_recovery >1 的情况会出现上文提到的循环报warning 问题（=1 没有问题），
原因：
MySQL 的源代码中显示  当innodb_purge_threads 和 innodb_force_recovery一起设置会出现loop循环
所以当需要设置innodb_force_recovery>1的时候需要关闭 innodb_purge_threads，设置为0（默认）。

四 小结 
   MySQL crash 或者 MySQL 数据库服务器 crash 会导致各种各样的问题 ，比如主备之间的 error 1594 (5.6 版本开启 crash-safe ，会最大程度上避免 error 1594的问题，以后会写5.6新特性介绍该功能 )， error  1236， 日志损坏， 数据文件损坏 ，等等，本案例只是其中的一种，细心从日志中找的相关错误提示，逐步解决即可。