MySQL數(shù)據(jù)庫(kù)是如何應(yīng)對(duì)故障恢復(fù)與數(shù)據(jù)恢復(fù)回滾的問(wèn)題呢？

介紹

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

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

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

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

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

MySQL的架構(gòu)

關(guān)于MySQL的簡(jiǎn)單架構(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ù)庫(kù)一定免不了要和他們打交道。

bin log

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

redo log

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

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

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

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

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

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

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

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

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

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

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

undo log

undo log 記錄的是與執(zhí)行SQL相反的SQL。例如，在user表，id為1的用戶(hù)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ǔ)句，那么相應(yīng)的，它會(huì)記錄一條insert語(yǔ)句。

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

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

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

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

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

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

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

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

兩階段提交

一條update語(yǔ)句的簡(jiǎn)單執(zhí)行過(guò)程

我們?cè)賮?lái)看執(zhí)行器和 InnoDB 引擎在執(zhí)行這個(gè)簡(jiǎn)單的 update 語(yǔ)句時(shí)的內(nèi)部流程。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

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

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

審核編輯：劉清