mysql數據庫故障處理（mysql常見故障和解決方法）

本文目錄一覽：

• 1、mysql數據庫出現問題怎麼辦？
• 2、mysql無法啟動
• 3、如何處理mysql數據庫MySQL服務啟動失敗，1067，進程意外停止。
• 4、如何修復MYSQL數據庫因斷電造成的數據損壞
• 5、mysql數據庫崩潰的原因？
• 6、MySQL數據庫服務器逐漸變慢 該如何分析與解決

mysql數據庫出現問題怎麼辦？

數據庫出現問題，首要的是儘快備份數據庫，如果數據庫損壞的話，找出最近日期的數據備份。

確認有數據庫備份後，根據數據庫錯誤的提示，一步一步地解決的，如果不是數據庫損壞，問題解決都不是很大的，如果是數據庫損壞的話，麻煩可就大了，只能考慮利用以前的數據庫備份了的

mysql無法啟動

故障處理

移除當前使用的 redo log 文件，然後可以試着啟動數據庫，結果啟動失敗！

提示：

[ERROR] InnoDB: Page [page id: space=0, page number=0] log sequence number 178377412422 is in the future! Current system log sequence number 165909011496.

這樣的錯誤，這是因為 MySQL writer 線程按照配置的時間間隔以 page 為單位刷新 buffer 數據到磁盤。當數據刷新到磁盤的時候，新寫入磁盤的 page 包含了較新的 LSN，此時系統 system 表空間頭的 LSN 並沒有同步更新，通常這是檢查點線程的工作。在正常的崩潰恢復中，MySQL 可以藉助 redo log 來進行前滾和回滾，但是此時 redo log 已經被我們刪掉了，MySQL 無法進行恢復操作。此時，我們設置 innodb_force_recovery=3 來強制啟動 MySQL，仍然啟動不成功，改成 4 後啟動了！

再使用 mysqldump 導出備份，結果噩夢又降臨了！MySQL 又 crash 了。

提示：

InnDB: Failed to find tablespace for table……

設置參數 innodb_force_recovery=5，數據庫仍然啟動失敗，再設置成 6，啟動成功！用 sqldump 順利把數據備份出來了！

再初始化數據庫，把剛剛備份的數據庫導入，數據庫恢復成功完成！

參數說明

這裡的關鍵是設置 innodb_force_recovery 參數，對應這個參數的說明如下：

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：不執行前滾的操作。

如何處理mysql數據庫MySQL服務啟動失敗，1067，進程意外停止。

我在網上找到解決方案：

1、在MY.INI文件中的 [mysqld] 中增加一行

tmpdir=”D:/MySQL/data/”

修改後，還是啟動不了或者能啟動但關機後又出現同樣問題，接着我做了第二步，重啟正常。

2、刪除DATA目錄下除數據庫文件夾外的其他文件，重啟mysql，問題解決。

或者也可以：

先卸載，然後將原來存儲數據的目錄刪除，再重裝ok。

如何修復MYSQL數據庫因斷電造成的數據損壞

修復MYSQL數據庫因斷電造成的數據損壞在使用MySQL數據庫的時候，都碰到過因斷電造成數據庫損壞的情況，大家都知道，斷電或非正常關機是導致MySQL數據庫出現錯誤最常見的原因，如何恢復MySQL數據庫是大家都非常頭痛的問題。目前有方法可以幫助大家恢復損壞的MySQL數據庫嗎？當用戶出現斷電造成的MySQL數據庫丟失損壞時，如果能進入MySQL軟件，但是提示錯誤信息，用戶可以通過“系統維護”—“數據庫壓縮修復”，壓縮下數據庫（有些軟件在“系統設置”—“系統維護”—“數據庫備份恢復”中），這種方法只適合一小部分的數據庫故障修復，功能性並不高。現在網絡上有兩種比較推薦使用的MySQL數據庫恢復方法，一種方法使用MySQL(和PHP搭配之最佳組合)的check table和repair table 的sql語句，另一種方法是使用MySQL(和PHP搭配之最佳組合)提供的多個myisamchk， isamchk數據檢測恢復工具。在很多用戶看來，這兩個方法都比較複雜，並不適合大多數的用戶使用。另外，這兩種方法並不能有效的恢復MySQL數據庫，可能還會造成數據庫被進一步損壞，造成大家無法挽回的損失。根據以上幾個原因，這兩種MySQL數據庫恢復方法並不建議大家使用。。數據庫被損壞分以下幾種情況：1、嚴重損壞2、輕度損壞3、有些表被損壞或有些表的部分記錄被損壞如何修復MYSQL數據庫因斷電造成的數據損壞

mysql數據庫崩潰的原因？

MySQL 在崩潰恢復時，會遍歷打開所有 ibd 文件的 header page 驗證數據字典的準確性，如果 MySQL 中包含了大量表，這個校驗過程就會比較耗時。 MySQL 下崩潰恢復確實和表數量有關，表總數越大，崩潰恢復時間越長。另外磁盤 IOPS 也會影響崩潰恢復時間，像這裡開發庫的 HDD IOPS 較低，因此面對大量的表空間，校驗速度就非常緩慢。另外一個發現，MySQL 8 下正常啟用時居然也會進行表空間校驗，而故障恢復時則會額外再進行一次表空間校驗，等於校驗了 2 遍。不過 MySQL 8.0 里多了一個特性，即表數量超過 5W 時，會啟用多線程掃描，加快表空間校驗過程。

如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛？查閱了資料，方法主要有兩種：

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那麼 validate = false，即可以跳過表空間校驗。實際測試的時候設置 innodb_force_recovery =1，也就是強制恢復跳過壞頁，就可以跳過校驗，然後重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復後非常耗時的表空間校驗過程，快速啟動 MySQL，個人目前暫時未發現有什麼隱患。2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了，只需要打開一個 ibdata 文件即可，大大節省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理後，感覺共享表空間在很多業務環境下，反而更有優勢。

臨時冒出另外一種解決想法，即用 GDB 調試崩潰恢復，通過臨時修改 validate 變量值讓 MySQL 跳過表空間驗證過程，然後讓 MySQL 正常關閉，重新啟動就可以正常啟動了。但是實際測試發現，如果以 debug 模式運行，確實可以臨時修改 validate 變量，跳過表空間驗證過程，但是 debug 模式下代碼運行效率大打折扣，反而耗時更長。而以非 debug 模式運行，則無法修改 validate 變量，想法破滅。

MySQL數據庫服務器逐漸變慢 該如何分析與解決

MySQL 在崩潰恢復時，會遍歷打開所有 ibd 文件的 header page 驗證數據字典的準確性，如果 MySQL 中包含了大量表，這個校驗過程就會比較耗時。 MySQL 下崩潰恢復確實和表數量有關，表總數越大，崩潰恢復時間越長。另外磁盤 IOPS 也會影響崩潰恢復時間，像這裡開發庫的 HDD IOPS 較低，因此面對大量的表空間，校驗速度就非常緩慢。另外一個發現，MySQL 8 下正常啟用時居然也會進行表空間校驗，而故障恢復時則會額外再進行一次表空間校驗，等於校驗了 2 遍。不過 MySQL 8.0 里多了一個特性，即表數量超過 5W 時，會啟用多線程掃描，加快表空間校驗過程。

如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛？查閱了資料，方法主要有兩種：

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那麼 validate = false，即可以跳過表空間校驗。實際測試的時候設置 innodb_force_recovery =1，也就是強制恢復跳過壞頁，就可以跳過校驗，然後重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復後非常耗時的表空間校驗過程，快速啟動 MySQL，個人目前暫時未發現有什麼隱患。2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了，只需要打開一個 ibdata 文件即可，大大節省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理後，感覺共享表空間在很多業務環境下，反而更有優勢。

臨時冒出另外一種解決想法，即用 GDB 調試崩潰恢復，通過臨時修改 validate 變量值讓 MySQL 跳過表空間驗證過程，然後讓 MySQL 正常關閉，重新啟動就可以正常啟動了。但是實際測試發現，如果以 debug 模式運行，確實可以臨時修改 validate 變量，跳過表空間驗證過程，但是 debug 模式下代碼運行效率大打折扣，反而耗時更長。而以非 debug 模式運行，則無法修改 validate 變量，想法破滅。