mysql連接失敗是什麼原因?作者：姚遠專注于 Oracle、MySQL 數據庫多年，Oracle 10G 和 12C OCM，MySQL 5.6，5.7，8.0 OCP現在鼎甲科技任顧問，為同事和客戶提高數據庫培訓和技術支持服務，下面我們就來聊聊關于mysql連接失敗是什麼原因?接下來我們就一起去了解一下吧!

mysql連接失敗是什麼原因

作者：姚遠

專注于 Oracle、MySQL 數據庫多年，Oracle 10G 和 12C OCM，MySQL 5.6，5.7，8.0 OCP。現在鼎甲科技任顧問，為同事和客戶提高數據庫培訓和技術支持服務。

本文來源：原創投稿

*愛可生開源社區出品，原創内容未經授權不得随意使用，轉載請聯系小編并注明來源。

---

故障描述

MySQL 數據庫服務器的 CPU 和主闆都換了，重新開機，發現 MySQL 無法啟動！！！

提示：

Ignoring the redo log due to missing MLOG_CHECKPOINT between the checkpoint .... and ...

故障分析

這個問題出現在 MySQL 5.7 之後的版本，主要的原因是 MySQL 會在最新的 checkpoint 完成後都會在 redo log 寫一個一字節的 MLOG_CHECKPOINT 标記，用來标記在此之前的 redo 都已 checkpoint 完成。如果處于任何原因沒有找到這個标記，那麼整個 redo log 文件都會被忽略。出現這個錯誤的話，最好是有備份進行恢複，如果沒有做好備份，那隻能采取非常規的啟動方式，但可能造成數據丢失。

故障處理

移除當前使用的 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：不執行前滾的操作。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部