MySQL 崩潰無法啟動？innodb_force_recovery 緊急搶救實戰指南

磁碟故障、掉電、殺進程、OOM Killer 導致 MySQL 異常關閉，重啟時卡在 InnoDB: Doing recovery... 階段最終報 mysqld got signal 11 (Segmentation fault) 退出。此時數據頁、Redo Log、Undo Log 可能已損壞，正常崩潰恢復失效。innodb_force_recovery 是最後的「核武器級」搶救手段 — **跳過損壞頁檢查、跳過事務回滾、跳過 Redo Log 前滾**，強行拉起實例導出數據重建。本文記錄一次真實生產搶救全過程。

故障現場

• 環境：MariaDB 5.5.37 (兼容 MySQL 5.5)
• 觸發：磁碟陣列故障導致主機硬崩潰
• 錯誤日誌關鍵片段：

  InnoDB: Doing recovery: scanned up to log sequence number 9120034833
  150125 16:12:51 InnoDB: Starting an apply batch of log records to the database...
  InnoDB: Progress in percents: 5 6 7 ... 40
  150125 16:12:51 [ERROR] mysqld got signal 11 ;  -- Segfault，恢復過程中訪問非法記憶體

分析：Redo Log 在應用階段遇到損壞頁/邏輯錯誤觸發 Segfault，屬於 **嚴重元數據/數據頁損壞**，常規恢復無效。

innodb_force_recovery 參數詳解 (1-6 級遞增)

在 [mysqld] 區段設置 innodb_force_recovery = N，級別包含關係 (N 級包含 N-1 級所有行為)：

核心限制：innodb_force_recovery > 0 時，實例進入 **唯讀模式** — 僅允許 SELECT、CREATE、DROP，**禁止 INSERT/UPDATE/DELETE**。

關鍵坑點：innodb_purge_threads 與 force_recovery 衝突導致無限循環

MySQL 5.5/5.6 源碼邏輯：啟動時等待 Purge Thread 啟動，但 force_recovery >= 2 會阻止 Master Thread，導致 Purge Thread 永不啟動，主線程陷入 Waiting for the background threads to start 無限循環。

解法：同時設置 innodb_purge_threads = 0 (禁用獨立 Purge Thread)。

實戰搶救步驟 (本案例成功路徑)

1. 修改配置 (my.cnf)：

   [mysqld]
   innodb_force_recovery = 6
   innodb_purge_threads = 0

2. 重啟 MySQL：

   systemctl restart mysqld
   # 或 service mysql restart

   日誌顯示 Crash recovery finished.、ready for connections. → **實例掛載成功！**
3. 立即導出數據 (唯讀模式下)**：

   mysqldump -u root -p --all-databases --single-transaction --routines --triggers > /backup/full_dump_$(date +%F).sql

   必須加 --single-transaction** 保證導出一致性視圖 (雖然實例唯讀，但習慣加上)。
4. 驗證導出文件完整性** (行數、檔案大小、關鍵表抽樣)。
5. 恢復配置並重建**：

   # 註釋 force_recovery 恢復 purge_threads
   # innodb_force_recovery = 6
   # innodb_purge_threads = 0  (恢復預設 1 或 4)
   
   systemctl restart mysqld  # 正常模式啟動
   mysql -u root -p < /backup/full_dump_$(date +%F).sql  # 導入新實例