資料庫機器的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日志檔案都會被忽略，出現這個錯誤的話，最好是有備份進行恢復，如果沒有做好備份，那只能采取非常規的啟動方式，但可能造成資料丟失，
移除當前使用的redo日志檔案，然后可以試著啟動資料庫，結果啟動失敗！
這時的提示：[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日志來進行前滾和回滾，但是此時redo日志已經被我們刪掉了，mysql無法進行恢復操作，此時，我們設定innodb_force_recovery=3來強制啟動mysql，仍然啟動不成功，改成4，啟動了！
再使用mysqldump匯出備份，結果噩夢又降臨了！
設定引數innodb_force_recovery=5，資料庫仍然啟動失敗，再設定成6，啟動成功！用sqldump順利吧資料備份出來了！
再初始化資料庫，把剛剛備份的資料庫匯入，行了！資料庫恢復成功完成！
這里的關鍵是設定innodb_force_recovery引數，對應這個引數的說明如下：
- (SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的corrupt頁，
- (SRV_FORCE_NO_BACKGROUND):阻止主執行緒的運行，如主執行緒需要執行full purge操作，會導致crash
- (SRV_FORCE_NO_TRX_UNDO):不執行事務回滾操作，
- (SRV_FORCE_NO_IBUF_MERGE):不執行插入緩沖的合并操作，
- (SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存盤引擎會將未提交的事務視為已提交
- (SRV_FORCE_NO_LOG_REDO):不執行前滾的操作，
CSDN認證博客專家
10G OCM
12C OCM
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/150750.html
標籤：AI
上一篇：服務報錯:java.sql.SQLException: Field ‘***‘ doesn‘t have a default value