作者：姚遠(yuǎn)
專(zhuān)注于 Oracle、MySQL 數(shù)據(jù)庫(kù)多年，Oracle 10G 和 12C OCM，MySQL 5.6，5.7，8.0 OCP。現(xiàn)在鼎甲科技任顧問(wèn)，為同事和客戶(hù)提高數(shù)據(jù)庫(kù)培訓(xùn)和技術(shù)支持服務(wù)。
本文來(lái)源：原創(chuàng)投稿
*愛(ài)可生開(kāi)源社區(qū)出品，原創(chuàng)內(nèi)容未經(jīng)授權(quán)不得隨意使用，轉(zhuǎn)載請(qǐng)聯(lián)系小編并注明來(lái)源。
故障描述
MySQL 數(shù)據(jù)庫(kù)服務(wù)器的 CPU 和主板都換了，重新開(kāi)機(jī)，發(fā)現(xiàn) MySQL 無(wú)法啟動(dòng)！！！
提示：
Ignoring the redo log due to missing MLOG_CHECKPOINT between the checkpoint .... and ...
故障分析
這個(gè)問(wèn)題出現(xiàn)在 MySQL 5.7 之后的版本，主要的原因是 MySQL 會(huì)在最新的 checkpoint 完成后都會(huì)在 redo log 寫(xiě)一個(gè)一字節(jié)的 MLOG_CHECKPOINT 標(biāo)記，用來(lái)標(biāo)記在此之前的 redo 都已 checkpoint 完成。如果處于任何原因沒(méi)有找到這個(gè)標(biāo)記，那么整個(gè) redo log 文件都會(huì)被忽略。出現(xiàn)這個(gè)錯(cuò)誤的話(huà)，最好是有備份進(jìn)行恢復(fù)，如果沒(méi)有做好備份，那只能采取非常規(guī)的啟動(dòng)方式，但可能造成數(shù)據(jù)丟失。
故障處理
移除當(dāng)前使用的 redo log 文件，然后可以試著啟動(dòng)數(shù)據(jù)庫(kù)，結(jié)果啟動(dòng)失敗！
提示：
[ERROR] InnoDB: Page [page id: space=0, page number=0] log sequence number 178377412422 is in the future! Current system log sequence number 165909011496.
這樣的錯(cuò)誤，這是因?yàn)?MySQL writer 線(xiàn)程按照配置的時(shí)間間隔以 page 為單位刷新 buffer 數(shù)據(jù)到磁盤(pán)。當(dāng)數(shù)據(jù)刷新到磁盤(pán)的時(shí)候，新寫(xiě)入磁盤(pán)的 page 包含了較新的 LSN，此時(shí)系統(tǒng) system 表空間頭的 LSN 并沒(méi)有同步更新，通常這是檢查點(diǎn)線(xiàn)程的工作。在正常的崩潰恢復(fù)中，MySQL 可以借助 redo log 來(lái)進(jìn)行前滾和回滾，但是此時(shí) redo log 已經(jīng)被我們刪掉了，MySQL 無(wú)法進(jìn)行恢復(fù)操作。此時(shí)，我們?cè)O(shè)置 innodb_force_recovery=3 來(lái)強(qiáng)制啟動(dòng) MySQL，仍然啟動(dòng)不成功，改成 4 后啟動(dòng)了！
再使用 mysqldump 導(dǎo)出備份，結(jié)果噩夢(mèng)又降臨了！MySQL 又 crash 了。
提示：
InnDB: Failed to find tablespace for table......
設(shè)置參數(shù) innodb_force_recovery=5，數(shù)據(jù)庫(kù)仍然啟動(dòng)失敗，再設(shè)置成 6，啟動(dòng)成功！用 sqldump 順利把數(shù)據(jù)備份出來(lái)了！
再初始化數(shù)據(jù)庫(kù)，把剛剛備份的數(shù)據(jù)庫(kù)導(dǎo)入，數(shù)據(jù)庫(kù)恢復(fù)成功完成！
參數(shù)說(shuō)明
這里的關(guān)鍵是設(shè)置 innodb_force_recovery 參數(shù)，對(duì)應(yīng)這個(gè)參數(shù)的說(shuō)明如下：
1. SRV_FORCE_IGNORE_CORRUPT：忽略檢查到的 corrupt 頁(yè)；
2. SRV_FORCE_NO_BACKGROUND：阻止主線(xiàn)程的運(yùn)行，如主線(xiàn)程需要執(zhí)行 full purge 操作，會(huì)導(dǎo)致 crash；
3. SRV_FORCE_NO_TRX_UNDO：不執(zhí)行事務(wù)回滾操作；
4. SRV_FORCE_NO_IBUF_MERGE：不執(zhí)行插入緩沖的合并操作；
5. SRV_FORCE_NO_UNDO_LOG_SCAN：不查看重做日志，InnoDB 存儲(chǔ)引擎會(huì)將未提交的事務(wù)視為已提交；
6. SRV_FORCE_NO_LOG_REDO：不執(zhí)行前滾的操作。
