介紹

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

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

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

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

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

MySQL的架構(gòu)

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



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

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

MySQL的日志系統(tǒng)

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

bin log

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

redo log

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

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

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

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

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

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

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

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

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

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

要理解 crash-safe 這個概念，可以想想我們前面賒賬記錄的例子。只要賒賬記錄記在了粉板上或?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中則會記錄update table user set age = 32 where id = 1，如果執(zhí)行的是delete語句，那么相應(yīng)的，它會記錄一條insert語句。

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

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

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

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

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

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

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

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

兩階段提交

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

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

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

審核編輯：劉清