【案例】利用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， 日誌損壞，資料檔案損壞 ，等等，本案例只是其中的一種，細心從日誌中找的相關錯誤提示，逐步解決即可。