上上周，一產品的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。