MySQL [ERROR] [MY-013183]

2022 年 3 月 8 日
筆記
資料庫

[ERROR] [MY-013183] [InnoDB] Assertion failure，回顧記錄一次因資料庫（MySql 8.0）操作不當導致的生產事故😓順便記錄下正常重啟發生的意外和解決方法（關於 [MY-013183] [InnoDB] 論壇描述，MY-013183隻是斷言拋出問題記憶體問題，應該是由於緩衝區落盤發生意外導致的，具體處理需要結合錯誤詳細資訊進行分析。如果文檔中有不對的地方或有更好的方法建議，希望大家不吝賜教）

資料庫重啟，沒啟動成功

業務正常一般不會去操作資料庫，除非宕機😆。無奈資料庫安裝配置存在問題需要修改配置文件使其永久生效，數據生產較快當時已經有千萬的量了，么辦法只有當天晚上進行資料庫調整，結果資料庫絲毫不給面子直接拋出一個錯誤[ERROR] [MY-013183] 。

好在通過錯誤詳細分析問題可以通過資料庫強制恢復，通過配置文件設置innodb_force_recover(官網描述可連接查看)從1到6成功啟動（這個情況最多設置到4資料庫就會恢復，如果你設置到6才啟動上那就只有恭喜你了），再取消innodb_force_recover配置重啟就可以收工了

資料庫意外重啟，拋異常連接不上

資料庫意外無法正常運行（那天業務系統走得很安詳，我也走得很安詳），上伺服器一看根目錄滿了，這也是沒誰了反手就是一個贊🙃（資料庫安裝沒有使用大存儲卷），麻溜清理了磁碟，釋放好空間開始重啟資料庫（以為可以正常啟動，結果當頭一棒）查看資料庫服務狀態是runing，高高興興的去連接好傢夥連不上（連埠沒監聽）給我表裡不一😡。

發來的資料庫錯誤資訊 [ERROR] [MY-013183] [InnoDB] Assertion failure: fil0fil.cc:10754:initial_fsize == (file->size * phy_page_size) thread 140530362709760，當我看到這個斷言的時候心都涼了半截，innodb_force_recover設置1-6設置了兩遍，都設置到16了（6以上都是安6處理，一般都是1-6）也沒恢復回來。現在分析下錯誤資訊應該就是落盤idb文件分頁有損壞導致斷言過不了，當時不行啊沒有分析的時間電話都打爆了，領導都插著手站背後看得我瑟瑟發抖，只有簡單整理下打算放棄當前資料庫實例，通過資料庫源文件進行資料庫還原（別問為什麼不從備份中還原，問就是還沒開始做備份🙃我就只知道這些了）通過百度大法明確了處理流程（只有逐表恢復）

1. 拷貝舊庫data目錄，處理事故首先確保拷貝，避免反向修復無法回頭也是為了保護事故現場（此處省略，後面操作都是用拷貝的這部分文件）
2. 創建同版本臨時資料庫實例（此處省略）
3. 創建與原資料庫一致的資料庫及表，可以從測試環境導出結構調整與生產環境一致。如果這個沒有那我只有鼓掌了👏但是也不要慌可通過 ibd2sdi — InnoDB 表空間 SDI 提取
1. ① 表名
2. ② 列名和類型，列對象裡面有類型對應的具體名稱
3. ③ 長度
  
  4. 備份臨時資料庫data目錄（此處省略）
4. 5. 舊庫ibd替換新的ibd文件，逐個修改替換表的ibd文件（如果是MyISAM引擎的表，此階段應該就可以使用了）
5. .ibd文件包含tablespace id，需要修改恢複數據.ibd文件的tablespace id和臨時表建立的相同標記處為修改處需保持一致
7. vi模式下，輸入 :%!xxd 進行16進位編輯，使用 :%!xxd -r 轉換為二進位保存或者使用winHex(編輯16進位)
8. 另一種ibd解綁和綁定方法是通過命令（這個應該是之前版本的，我嘗試後失敗了，僅供了解）
  1. 解除綁定：alter table user discard tablespace;（執行完sql後，表現為表的ibd文件被刪除，但是千萬不要自己手動刪除）
  2. 綁定數據表.frm和數據.idb的關係:alter table user import tablespace;
9. 註：拷貝後注意許可權是正確，替換臨時庫ibd文件後無法正常啟動可以清理或替換掉ib_logfile0、ib_logfile1，配置innodb_force_recover=6
10. 6. 備份臨時庫還原至正式新資料庫實例中
11. 備份：mysqldump -h 主機名 –P 埠 -u 用戶名 –p 資料庫名 > 備份文件.sql
12. 還原：mysql> source 備份文件.sql
13. 註：備份文件.sql會清理一次表然後再創建寫入資料庫
15. 以上6步操作數據逐步恢復，本以為萬事大吉，可天有不測風雲。ibd分頁壞了，當讀取到壞頁位置時該出問題的時候還是得出問題，讀取到損壞頁時資料庫會宕掉重啟日誌會輸出多少頁讀取異常（當時忙著解決問題沒存錯誤資訊😅），只有找了個ibd操作工具Inno_space清理掉損壞頁那一頁的數據就丟了（有幾頁壞了丟了兩三百條數據），好在損壞頁數據可以不用完全恢復。
  
  最後
16. 雖然數據大部分恢復了，但是頁壞了的那部分數據沒恢復，如果這部份數據是比較重要，損失就相當嚴重了。
17. 希望大家伺服器一定要做好相關監控（cpu、記憶體、網路、磁碟等）、資料庫按照相關備份方案做好備份
18. 也希望大家永遠也不需要參考這篇文章，都是教訓呀。
19. 歡迎大家留言討論
  
  參考引用
20. 關於 [MY-013183] [InnoDB] CD Tavares 論壇描述：//forums.mysql.com/read.php?22,672274,672274
21. 官網強制恢復InnoDB：//dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
22. 官網ibd2sdi — InnoDB 表空間 SDI 提取實用程式：//dev.mysql.com/doc/refman/8.0/en/ibd2sdi.html
23. HuaLingPiaoXue MYSQL8.0 根據IBD文件查看錶結構：//blog.csdn.net/HuaLingPiaoXue/article/details/104953594
24. 巴老闆 mysql frm ibd 恢復工具_MySQL innodb引擎下根據.frm和.ibd文件恢復表結構和數據：//blog.csdn.net/weixin_36275231/article/details/113253297
25. Inno_space工具：//github.com/baotiao/inno_space

Tags: 資料庫