介紹

今天這篇文章，我想聊一聊MySQL數(shù)據(jù)庫是如何應(yīng)對故障恢復(fù)，與數(shù)據(jù)恢復(fù)回滾的問題。一個(gè)最基本的數(shù)據(jù)庫，應(yīng)當(dāng)可以做到以下幾點(diǎn)：

數(shù)據(jù)持久化，可以將數(shù)據(jù)保存到磁盤，服務(wù)重啟數(shù)據(jù)依然存在。

可以按照某種關(guān)系存儲(chǔ)數(shù)據(jù)，如果你用過IO流，那么你會(huì)發(fā)現(xiàn)整理數(shù)據(jù)也是一件復(fù)雜的事情。我是該追加寫呢還是找到某條數(shù)據(jù)位置再進(jìn)行寫呢？這是個(gè)很復(fù)雜的問題。

快速查找。你想想自己如果將數(shù)據(jù)寫入txt，那又如何高效的去找到某條數(shù)據(jù)？支持隨機(jī)查找嗎？

故障恢復(fù)與數(shù)據(jù)回滾，倘若你的服務(wù)斷電了，如何確保數(shù)據(jù)一定是寫入到文件的？若是誤刪或誤改了某條數(shù)據(jù)，你又如何進(jìn)行恢復(fù)？

MySQL的架構(gòu)

關(guān)于MySQL的簡單架構(gòu)圖。



MySQL大致可以分為服務(wù)層與存儲(chǔ)引擎層。在單獨(dú)抽離了存儲(chǔ)引擎層后，你可以選擇合適的引擎，例如InnoDb，MyIsam，Memory等等。

關(guān)于不同的存儲(chǔ)引擎，使用的方式可能不同。我主要想講的是InnoDb引擎，MySQL 5.5 版本后默認(rèn)的存儲(chǔ)引擎。

MySQL的日志系統(tǒng)

MySQL有三大日志，分別是重做日志(redo log)，二進(jìn)制日志(bin log)，以及回滾日志(undo log)。這三個(gè)日志非常重要，學(xué)習(xí)MySQL數(shù)據(jù)庫一定免不了要和他們打交道。

bin log

bin log是Server層的日志，無論使用的是什么引擎，都可以使用這種日志。這個(gè)日志記錄的是邏輯日志，就是SQL語句。例如insert into table set xx = xx在bin log中記錄的也是這樣的一條SQL。而且bin log 采用的是追加寫的形式，也即是說在寫完一個(gè)bin log文件之后，不會(huì)覆蓋前面的，而是新開一個(gè)文件繼續(xù)追加寫。

redo log

redo log 是存儲(chǔ)引擎InnoDB所提供的日志模塊。個(gè)日志記錄的是，物理日志。記錄的是當(dāng)前SQL在哪一個(gè)數(shù)據(jù)頁上將什么數(shù)據(jù)修改為了什么數(shù)據(jù)。

關(guān)于redo log，我很喜歡林曉斌老師在《MySQL實(shí)戰(zhàn)45講》中講的例子，酒館的賬本與黑板的例子。在古時(shí)候的酒館中，老板會(huì)有一本賬本，以及身后的一塊黑板。倘若今天有人去喝酒，賒賬。在很忙的時(shí)候，老板會(huì)將這條記錄寫在黑板上，后續(xù)等到酒館打烊了，不忙的時(shí)候，才將這個(gè)記錄寫進(jìn)自己的賬本中。

事實(shí)上，在MySQL也是這么做的，如果每一次的更新操作都需要寫進(jìn)磁盤，然后磁盤也要找到對應(yīng)的那條記錄，然后再更新，整個(gè)過程 IO 成本、查找成本都很高。

而黑板和賬本配合的整個(gè)過程，其實(shí)就是 MySQL中常說到的WAL（Write-Ahead Logging）技術(shù)，WAL 的全稱是 ，它的關(guān)鍵點(diǎn)就是先寫日志，再寫磁盤，也就是先寫黑板，等不忙的時(shí)候再寫賬本。

具體來說，當(dāng)有一條記錄需要更新的時(shí)候，InnoDB 引擎就會(huì)先把記錄寫到 redo log（黑板）里面，并更新內(nèi)存，這個(gè)時(shí)候更新就算完成了。同時(shí)，InnoDB 引擎會(huì)在適當(dāng)?shù)臅r(shí)候，將這個(gè)操作記錄更新到磁盤里面，而這個(gè)更新往往是在系統(tǒng)比較空閑的時(shí)候做，這就像酒館打烊之后老板做的事。

如果今天賒賬的不多，掌柜可以等打烊后再整理。但如果某天賒賬的特別多，黑板寫滿了，又怎么辦呢？這個(gè)時(shí)候掌柜只好放下手中的活兒，把粉板中的一部分賒賬記錄更新到賬本中，然后把這些記錄從粉板上擦掉，為記新賬騰出空間。

與此類似，InnoDB 的 redo log 是固定大小的，比如可以配置為一組 4 個(gè)文件，每個(gè)文件的大小是 1GB，那么這塊“黑板”總共就可以記錄 4GB 的操作。從頭開始寫，寫到末尾就又回到開頭循環(huán)寫，如下面這個(gè)圖所示。

write pos 是當(dāng)前記錄的位置，一邊寫一邊后移。checkpoint 是當(dāng)前要擦除的位置，也是往后推移并且循環(huán)的，擦除記錄前要把記錄更新到數(shù)據(jù)文件。

write pos 和 checkpoint 之間的是“黑板”上還空著的部分，可以用來記錄新的操作。如果 write pos 追上 check point，表示“黑板”滿了，這時(shí)候不能再執(zhí)行新的更新，得停下來先擦掉一些記錄，把 checkpoint 推進(jìn)一下。

有了 redo log，InnoDB 就可以保證即使數(shù)據(jù)庫發(fā)生異常重啟，之前提交的記錄都不會(huì)丟失，這個(gè)能力稱為crash-safe。

要理解 crash-safe 這個(gè)概念，可以想想我們前面賒賬記錄的例子。只要賒賬記錄記在了粉板上或?qū)懺诹速~本上，之后即使掌柜忘記了，比如突然停業(yè)幾天，恢復(fù)生意后依然可以通過賬本和粉板上的數(shù)據(jù)明確賒賬賬目。

undo log

undo log 記錄的是與執(zhí)行SQL相反的SQL。例如，在user表，id為1的用戶age為32，那么執(zhí)行update table user set age = 45 where id = 1，那么undo log中則會(huì)記錄update table user set age = 32 where id = 1，如果執(zhí)行的是delete語句，那么相應(yīng)的，它會(huì)記錄一條insert語句。

undo log是MySQL用于事務(wù)模塊的重要日志，其中的MVCC（多版本并發(fā)控制技術(shù)）就與undo log版本鏈強(qiáng)相關(guān)。這篇文章重點(diǎn)不在此，因此不再多說。

MySQL如何做數(shù)據(jù)恢復(fù)

假如在今天的12點(diǎn)鐘，你誤刪了一個(gè)表。這種情況下該怎么恢復(fù)數(shù)據(jù)？首先，在使用MySQL時(shí)，通常會(huì)對其進(jìn)行全量備份。一般是一天、三天或每周一次。

那么此時(shí)應(yīng)當(dāng)找到最近的一次全量備份放入臨時(shí)庫中。

找到從全量備份的那一刻開始，將bin log重放到誤操作今天的12點(diǎn)鐘。

如此你便拿到了誤操作之前的數(shù)據(jù)，此時(shí)你可以將臨時(shí)庫中的數(shù)據(jù)按需要恢復(fù)回去。

MySQL如何做到故障恢復(fù)？（Crash-Safe的能力）

在InnoDB引擎下，MySQL支持事務(wù)。因此故障恢復(fù)還需要考慮到已提交的數(shù)據(jù)與未提交的數(shù)據(jù)。單獨(dú)靠bin log 或 redo log 是無法保證crash-safe的。

兩階段提交

一條update語句的簡單執(zhí)行過程

我們再來看執(zhí)行器和 InnoDB 引擎在執(zhí)行這個(gè)簡單的 update 語句時(shí)的內(nèi)部流程。

執(zhí)行器先找向存儲(chǔ)引擎找到 id = 1 這一行。id 作為主鍵，存儲(chǔ)引擎直接用B+樹搜索找到這一行。如果id=1 這行所在的數(shù)據(jù)頁已經(jīng)在內(nèi)存中，就直接返回給執(zhí)行器；否則就先從磁盤讀入內(nèi)存中，再返回。

執(zhí)行器拿到存儲(chǔ)引擎給的行數(shù)據(jù)，把這個(gè)值加上 1，比如原來是 n，現(xiàn)在為 n+1，得到了一行新的數(shù)據(jù)，再調(diào)用存儲(chǔ)引擎的接口寫入這一行新的數(shù)據(jù)。

引擎將這行新數(shù)據(jù)更新到內(nèi)存中，同時(shí)將這個(gè)更新操作記錄到 redo log 里面，此時(shí) redo log 處于prepare狀態(tài)。

執(zhí)行器生成這個(gè)操作的 binlog，并把 binlog 寫入磁盤。

執(zhí)行器調(diào)用引擎的提交事務(wù)接口，引擎把剛剛寫入的 redo log 改成提交commit狀態(tài)。

最后三步看起來有點(diǎn)復(fù)雜，InnoDB將 redo log 的寫入分為了兩個(gè)步驟：prepare階段和commit階段，這就是兩階段提交。

圖中白色框表示是在 InnoDB引擎內(nèi)部執(zhí)行的，綠色框表示的是在執(zhí)行器中執(zhí)行的。

為什么日志需要“兩階段提交”。

由于 redo log 與 bin log 是兩個(gè)層單獨(dú)的日志，如果不采用兩階段提交的方式，要么是先寫 redo log 再寫 bin log，或采用反的順序。

下面看看這兩種方式會(huì)出現(xiàn)什么問題。

仍然使用用前面的 update 語句來做例子。假設(shè)當(dāng)前 id=1 的行，字段 a 的值是 0，再假設(shè)執(zhí)行 update 語句過程中在寫完第一個(gè)日志后，第二個(gè)日志還沒有寫完期間發(fā)生了 crash，會(huì)出現(xiàn)什么情況呢？

先寫 redo log 后寫 binlog。假設(shè)在 redo log 寫完，binlog 還沒有寫完的時(shí)候，MySQL 進(jìn)程異常重啟。由于我們前面說過的，redo log 寫完之后，系統(tǒng)即使崩潰，仍然能夠把數(shù)據(jù)恢復(fù)回來，所以恢復(fù)后這一行 a 的值是 1。但是由于 binlog 沒寫完就 crash 了，這時(shí)候 binlog 里面就沒有記錄這個(gè)語句。因此，之后備份日志的時(shí)候，存起來的 binlog 里面就沒有這條語句。然后你會(huì)發(fā)現(xiàn)，如果需要用這個(gè) binlog 來恢復(fù)臨時(shí)庫的話，由于這個(gè)語句的 binlog 丟失，這個(gè)臨時(shí)庫就會(huì)少了這一次更新，恢復(fù)出來的這一行 a 的值就是 0，與原庫的值不同。

先寫 binlog 后寫 redo log。如果在 binlog 寫完之后 crash，由于 redo log 還沒寫，崩潰恢復(fù)以后這個(gè)事務(wù)無效，所以這一行 a 的值是 0。但是 binlog 里面已經(jīng)記錄了 “把 a 從 0 改成 1” 這個(gè)日志。所以，在之后用 binlog 來恢復(fù)的時(shí)候就多了一個(gè)事務(wù)出來，恢復(fù)出來的這一行 a 的值就是 1，與原庫的值不同。

可以看到，如果不使用“兩階段提交”，那么數(shù)據(jù)庫的狀態(tài)就有可能和用它的日志恢復(fù)出來的庫的狀態(tài)不一致。

簡單說，redo log 和 binlog 都可以用于表示事務(wù)的提交狀態(tài)，而兩階段提交就是讓這兩個(gè)狀態(tài)保持邏輯上的一致。

總結(jié)

學(xué)習(xí)了挺久的MySQL，突然又對其的數(shù)據(jù)恢復(fù)和故障恢復(fù)起了興趣，往深入了解又發(fā)現(xiàn)了之前一些之前無法理解的問題突然迎刃而解了。

MySQL的數(shù)據(jù)恢復(fù)與故障恢復(fù)依賴著幾個(gè)日志，bin log 與 redo log。bin log 是邏輯日志，記錄的是原始SQL語句，redo log 是InnoDB引擎支持的，是物理日志，記錄了在哪個(gè)數(shù)據(jù)頁修改了哪些數(shù)據(jù)，并且redo log 是循環(huán)寫日志。

MySQL需要按照一定時(shí)間進(jìn)行全量備份，這樣我們可以依靠最近一次全量備份點(diǎn)，以及從該點(diǎn)開始記錄的bin log進(jìn)行數(shù)據(jù)重放恢復(fù)

MySQL在使用了InnoDB引擎后，支持了事務(wù)，因此故障恢復(fù)需要確?？梢詤^(qū)分已提交事務(wù)與未提交事務(wù)。這個(gè)依賴于redo log 的二階段提交。

鏈接：https://juejin.cn/post/7304886129774805032

審核編輯：劉清