一次意外斷電導致mysql檔案損壞，啟動異常

sangxian發表於2022-02-18
MySql
1.中午一點的時候，機房的插座壞掉。
2.下午一點半以後陸續有人反饋網路連不上，檢查發現168那臺認證伺服器掛了，後面繼續觀察，發現整個實體機掛了。
3.後面去機房，發現是插座壞了，導致幾臺實體機斷電。
4.更換插座後伺服器陸續啟動
5.後面重啟資料庫，發現報錯：
 
6.看到了損壞的space id，首先想到的是找到對應的資料檔案，網上找到了一個小程式，可以根據ibd檔案找到對應的space id，
參見：《從ibd檔案獲取表空間id》
7.找了一圈，沒有找到對應的space id，後面發現不是ibd檔案壞了 ，是undo 檔案壞了，因為普通資料檔案有double write機制，意外斷電不會導致資料檔案的異常，除非磁碟大面積損壞。
8. 網上找了個方案，就是設定引數：設定  innodb_force_ recovery ，從1 到6 逐步嘗試。

 
1 (SRV_FORCE_IGNORE_CORRUPT): 忽略檢查到的 corrupt 頁。儘管檢測到了損壞的 page 仍強制服務執行。一般設定為該值即可，然後 dump 出庫表進行重建。
2 (SRV_FORCE_NO_BACKGROUND): 阻止主執行緒的執行，如主執行緒需要執行 full purge 操作，會導致 crash。 阻止 master thread 和任何 purge thread 執行。若 crash 發生在 purge 環節則使用該值。
3 (SRV_FORCE_NO_TRX_UNDO): 不執行事務回滾操作。
4 (SRV_FORCE_NO_IBUF_MERGE): 不執行插入緩衝的合併操作。如果可能導致崩潰則不要做這些操作。不要進行統計操作。該值可能永久損壞資料檔案。若使用了該值，則將來要刪除和重建輔助索引。
5 (SRV_FORCE_NO_UNDO_LOG_SCAN): 不檢視重做日誌，InnoDB 儲存引擎會將未提交的事務視為已提交。此時 InnoDB 甚至把未完成的事務按照提交處理。該值可能永久性的損壞資料檔案。
6 (SRV_FORCE_NO_LOG_REDO): 不執行前滾的操作。恢復時不做 redo log roll-forward。使資料庫頁處於廢止狀態，繼而可能引起 B 樹或者其他資料庫結構更多的損壞。



9.開啟資料庫，並把read_only=1 ,置成只讀模式，
10.用mysqldump 匯出所有的庫
11.pt-show-grants 匯出所有的使用者和許可權。
12.刪掉原來的 data目錄（刪之前可以先備份），並重新初始化。
13. 匯入資料庫
14.根據pt-show-grants匯出的許可權資訊,新建使用者並賦權。
15.有一次發現有一個資料檔案ibd損壞，導致整個庫都不能備份。


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/82406/viewspace-2856417/，如需轉載，請註明出處，否則將追究法律責任。

相關文章