mysql 資料庫無法啟動（Ignoring the redo log due to missing MLOG_CHECKPOINT between the checkpoint .... and)

資料庫機器的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引數，對應這個引數的說明如下：

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