MySQL的crash-safe原理是什么

這篇文章主要講解了“MySQL的crash-safe原理是什么”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“MySQL的crash-safe原理是什么”吧！

MySQL作為當(dāng)下最流行的開(kāi)源關(guān)系型數(shù)據(jù)庫(kù)，有一個(gè)很關(guān)鍵和基本的能力，就是必須能夠保證數(shù)據(jù)不會(huì)丟。那么在這個(gè)能力背后，MySQL是如何設(shè)計(jì)才能保證不管在什么時(shí)間崩潰，恢復(fù)后都能保證數(shù)據(jù)不會(huì)丟呢？有哪些關(guān)鍵技術(shù)支撐了這個(gè)能力？本文將為我們一一揭曉。

一、前言

MySQL 保證數(shù)據(jù)不會(huì)丟的能力主要體現(xiàn)在兩方面：

1. 能夠恢復(fù)到任何時(shí)間點(diǎn)的狀態(tài)；

2. 能夠保證MySQL在任何時(shí)間段突然奔潰，重啟后之前提交的記錄都不會(huì)丟失；

對(duì)于第一點(diǎn)將MySQL恢復(fù)到任何時(shí)間點(diǎn)的狀態(tài)，相信很多人都知道，只要保留有足夠的binlog，就能通過(guò)重跑binlog來(lái)實(shí)現(xiàn)。

對(duì)于第二點(diǎn)的能力，也就是本文標(biāo)題所講的crash-safe。即在 InnoDB 存儲(chǔ)引擎中，事務(wù)提交過(guò)程中任何階段，MySQL突然奔潰，重啟后都能保證事務(wù)的完整性，已提交的數(shù)據(jù)不會(huì)丟失，未提交完整的數(shù)據(jù)會(huì)自動(dòng)進(jìn)行回滾。這個(gè)能力依賴的就是redo log和unod log兩個(gè)日志。

因?yàn)閏rash-safe主要體現(xiàn)在事務(wù)執(zhí)行過(guò)程中突然奔潰，重啟后能保證事務(wù)完整性，所以在講解具體原理之前，先了解下MySQL事務(wù)執(zhí)行有哪些關(guān)鍵階段，后面才能依據(jù)這幾個(gè)階段來(lái)進(jìn)行解析。下面以一條更新語(yǔ)句的執(zhí)行流程為例，話不多說(shuō)，直接上圖：

從上圖可以清晰地看出一條更新語(yǔ)句在MySQL中是怎么執(zhí)行的，簡(jiǎn)單進(jìn)行總結(jié)一下：

1. 從內(nèi)存中找出這條數(shù)據(jù)記錄，對(duì)其進(jìn)行更新；

2. 將對(duì)數(shù)據(jù)頁(yè)的更改記錄到redo log中；

3. 將邏輯操作記錄到binlog中；

4. 對(duì)于內(nèi)存中的數(shù)據(jù)和日志，都是由后臺(tái)線程，當(dāng)觸發(fā)到落盤(pán)規(guī)則后再異步進(jìn)行刷盤(pán)；

上面演示了一條更新語(yǔ)句的詳細(xì)執(zhí)行過(guò)程，接下來(lái)咱們通過(guò)解答問(wèn)題，帶著問(wèn)題來(lái)剖析這個(gè)crash-safe的設(shè)計(jì)原理。

二、WAL機(jī)制

問(wèn)題：為什么不直接更改磁盤(pán)中的數(shù)據(jù)，而要在內(nèi)存中更改，然后還需要寫(xiě)日志，最后再落盤(pán)這么復(fù)雜？

這個(gè)問(wèn)題相信很多同學(xué)都能猜出來(lái)，MySQL更改數(shù)據(jù)的時(shí)候，之所以不直接寫(xiě)磁盤(pán)文件中的數(shù)據(jù)，最主要就是性能問(wèn)題。因?yàn)橹苯訉?xiě)磁盤(pán)文件是隨機(jī)寫(xiě)，開(kāi)銷大性能低，沒(méi)辦法滿足MySQL的性能要求。所以才會(huì)設(shè)計(jì)成先在內(nèi)存中對(duì)數(shù)據(jù)進(jìn)行更改，再異步落盤(pán)。但是內(nèi)存總是不可靠，萬(wàn)一斷電重啟，還沒(méi)來(lái)得及落盤(pán)的內(nèi)存數(shù)據(jù)就會(huì)丟失，所以還需要加上寫(xiě)日志這個(gè)步驟，萬(wàn)一斷電重啟，還能通過(guò)日志中的記錄進(jìn)行恢復(fù)。

寫(xiě)日志雖然也是寫(xiě)磁盤(pán)，但是它是順序?qū)?，相比隨機(jī)寫(xiě)開(kāi)銷更小，能提升語(yǔ)句執(zhí)行的性能（針對(duì)順序?qū)憺槭裁幢入S機(jī)寫(xiě)更快，可以比喻為你有一個(gè)本子，按照順序一頁(yè)一頁(yè)寫(xiě)肯定比寫(xiě)一個(gè)字都要找到對(duì)應(yīng)頁(yè)寫(xiě)快得多）。

這個(gè)技術(shù)就是大多數(shù)存儲(chǔ)系統(tǒng)基本都會(huì)用的WAL(Write Ahead Log)技術(shù)，也稱為日志先行的技術(shù)，指的是對(duì)數(shù)據(jù)文件進(jìn)行修改前，必須將修改先記錄日志。保證了數(shù)據(jù)一致性和持久性，并且提升語(yǔ)句執(zhí)行性能。

三、核心日志模塊

問(wèn)題：更新SQL語(yǔ)句執(zhí)行流程中，總共需要寫(xiě)3個(gè)日志，這3個(gè)是不是都需要，能不能進(jìn)行簡(jiǎn)化？

更新SQL執(zhí)行過(guò)程中，總共涉及MySQL日志模塊其中的三個(gè)核心日志，分別是redo log（重做日志）、undo log（回滾日志）、binlog（歸檔日志）。這里提前預(yù)告，crash-safe的能力主要依賴的就是這三大日志。

接下來(lái)，針對(duì)每個(gè)日志將單獨(dú)介紹各自的作用，然后再來(lái)評(píng)估是否能簡(jiǎn)化掉。

1、重做日志 redo log

redo log也稱為事務(wù)日志，由InnoDB存儲(chǔ)引擎層產(chǎn)生。記錄的是數(shù)據(jù)庫(kù)中每個(gè)頁(yè)的修改，而不是某一行或某幾行修改成怎樣，可以用來(lái)恢復(fù)提交后的物理數(shù)據(jù)頁(yè)（恢復(fù)數(shù)據(jù)頁(yè)，且只能恢復(fù)到最后一次提交的位置，因?yàn)樾薷臅?huì)覆蓋之前的）。

前面提到的WAL技術(shù)，redo log就是WAL的典型應(yīng)用，MySQL在有事務(wù)提交對(duì)數(shù)據(jù)進(jìn)行更改時(shí)，只會(huì)在內(nèi)存中修改對(duì)應(yīng)的數(shù)據(jù)頁(yè)和記錄redo log日志，完成后即表示事務(wù)提交成功，至于磁盤(pán)數(shù)據(jù)文件的更新則由后臺(tái)線程異步處理。由于redo log的加入，保證了MySQL數(shù)據(jù)一致性和持久性（即使數(shù)據(jù)刷盤(pán)之前MySQL奔潰了，重啟后仍然能通過(guò)redo log里的更改記錄進(jìn)行重放，重新刷盤(pán)），此外還能提升語(yǔ)句的執(zhí)行性能（寫(xiě)redo log是順序?qū)?，相比于更新?shù)據(jù)文件的隨機(jī)寫(xiě)，日志的寫(xiě)入開(kāi)銷更小，能顯著提升語(yǔ)句的執(zhí)行性能，提高并發(fā)量），由此可見(jiàn)redo log是必不可少的。

redo log是固定大小的，所以只能循環(huán)寫(xiě)，從頭開(kāi)始寫(xiě)，寫(xiě)到末尾就又回到開(kāi)頭，相當(dāng)于一個(gè)環(huán)形。當(dāng)日志寫(xiě)滿了，就需要對(duì)舊的記錄進(jìn)行擦除，但在擦除之前，需要確保這些要被擦除記錄對(duì)應(yīng)在內(nèi)存中的數(shù)據(jù)頁(yè)都已經(jīng)刷到磁盤(pán)中了。在redo log滿了到擦除舊記錄騰出新空間這段期間，是不能再接收新的更新請(qǐng)求，所以有可能會(huì)導(dǎo)致MySQL卡頓。（所以針對(duì)并發(fā)量大的系統(tǒng)，適當(dāng)設(shè)置redo log的文件大小非常重要?。。。?/p>

2、回滾日志 undo log

undo log顧名思義，主要就是提供了回滾的作用，但其還有另一個(gè)主要作用，就是多個(gè)行版本控制(MVCC)，保證事務(wù)的原子性。在數(shù)據(jù)修改的流程中，會(huì)記錄一條與當(dāng)前操作相反的邏輯日志到undo log中（可以認(rèn)為當(dāng)delete一條記錄時(shí)，undo log中會(huì)記錄一條對(duì)應(yīng)的insert記錄，反之亦然，當(dāng)update一條記錄時(shí)，它記錄一條對(duì)應(yīng)相反的update記錄），如果因?yàn)槟承┰驅(qū)е率聞?wù)異常失敗了，可以借助該undo log進(jìn)行回滾，保證事務(wù)的完整性，所以u(píng)ndo log也必不可少。

3、歸檔日志 binlog

binlog在MySQL的server層產(chǎn)生，不屬于任何引擎，主要記錄用戶對(duì)數(shù)據(jù)庫(kù)操作的SQL語(yǔ)句（除了查詢語(yǔ)句）。之所以將binlog稱為歸檔日志，是因?yàn)閎inlog不會(huì)像redo log一樣擦掉之前的記錄循環(huán)寫(xiě)，而是一直記錄（超過(guò)有效期才會(huì)被清理），如果超過(guò)單日志的最大值（默認(rèn)1G，可以通過(guò)變量 max_binlog_size 設(shè)置），則會(huì)新起一個(gè)文件繼續(xù)記錄。但由于日志可能是基于事務(wù)來(lái)記錄的(如InnoDB表類型)，而事務(wù)是絕對(duì)不可能也不應(yīng)該跨文件記錄的，如果正好binlog日志文件達(dá)到了最大值但事務(wù)還沒(méi)有提交則不會(huì)切換新的文件記錄，而是繼續(xù)增大日志，所以 max_binlog_size 指定的值和實(shí)際的binlog日志大小不一定相等。

正是由于binlog有歸檔的作用，所以binlog主要用作主從同步和數(shù)據(jù)庫(kù)基于時(shí)間點(diǎn)的還原。

那么回到剛才的問(wèn)題，binlog可以簡(jiǎn)化掉嗎？這里需要分場(chǎng)景來(lái)看：

1. 如果是主從模式下，binlog是必須的，因?yàn)閺膸?kù)的數(shù)據(jù)同步依賴的就是binlog；

2. 如果是單機(jī)模式，并且不考慮數(shù)據(jù)庫(kù)基于時(shí)間點(diǎn)的還原，binlog就不是必須，因?yàn)橛衦edo log就可以保證crash-safe能力了；但如果萬(wàn)一需要回滾到某個(gè)時(shí)間點(diǎn)的狀態(tài)，這時(shí)候就無(wú)能為力，所以建議binlog還是一直開(kāi)啟；

根據(jù)上面對(duì)三個(gè)日志的詳解，我們可以對(duì)這個(gè)問(wèn)題進(jìn)行解答：在主從模式下，三個(gè)日志都是必須的；在單機(jī)模式下，binlog可以視情況而定，保險(xiǎn)起見(jiàn)最好開(kāi)啟。

四、兩階段提交

問(wèn)題：為什么redo log要分兩步寫(xiě)，中間再穿插寫(xiě)binlog呢？

從上面可以看出，因?yàn)閞edo log影響主庫(kù)的數(shù)據(jù)，binlog影響從庫(kù)的數(shù)據(jù)，所以redo log和binlog必須保持一致才能保證主從數(shù)據(jù)一致，這是前提。

相信很多有過(guò)開(kāi)發(fā)經(jīng)驗(yàn)的同學(xué)都知道分布式事務(wù)，這里的redo log和binlog其實(shí)就是很典型的分布式事務(wù)場(chǎng)景，因?yàn)閮烧弑旧砭褪莾蓚€(gè)獨(dú)立的個(gè)體，要想保持一致，就必須使用分布式事務(wù)的解決方案來(lái)處理。而將redo log分成了兩步，其實(shí)就是使用了兩階段提交協(xié)議（Two-phase Commit，2PC）。

下面對(duì)更新語(yǔ)句的執(zhí)行流程進(jìn)行簡(jiǎn)化，看一下MySQL的兩階段提交是如何實(shí)現(xiàn)的：

從圖中可看出，事務(wù)的提交過(guò)程有兩個(gè)階段，就是將redo log的寫(xiě)入拆成了兩個(gè)步驟：prepare和commit，中間再穿插寫(xiě)入binlog。

如果這時(shí)候你很疑惑，為什么一定要用兩階段提交呢，如果不用兩階段提交會(huì)出現(xiàn)什么情況，比如先寫(xiě)redo log，再寫(xiě)binlog或者先寫(xiě)binlog，再寫(xiě)redo log不行嗎？下面我們用反證法來(lái)進(jìn)行論證。

我們繼續(xù)用update T set c=c+1 where id=2這個(gè)例子，假設(shè)id=2這一條數(shù)據(jù)的c初始值為0。那么在redo log寫(xiě)完，binlog還沒(méi)有寫(xiě)完的時(shí)候，MySQL進(jìn)程異常重啟。由于redo log已經(jīng)寫(xiě)完了，系統(tǒng)重啟后會(huì)通過(guò)redo log將數(shù)據(jù)恢復(fù)回來(lái)，所以恢復(fù)后這一行c的值是1。但是由于binlog沒(méi)寫(xiě)完就crash了，這時(shí)候binlog里面就沒(méi)有記錄這個(gè)語(yǔ)句。因此，不管是現(xiàn)在的從庫(kù)還是之后通過(guò)這份binlog還原臨時(shí)庫(kù)都沒(méi)有這一次更新，c的值還是0，與原庫(kù)的值不同。

同理，如果先寫(xiě)binlog，再寫(xiě)redo log，中途系統(tǒng)crash了，也會(huì)導(dǎo)致主從不一致，這里就不再詳述。

所以將redo log分成兩步寫(xiě)，即兩階段提交，才能保證redo log和binlog內(nèi)容一致，從而保證主從數(shù)據(jù)一致。

兩階段提交雖然能夠保證單事務(wù)兩個(gè)日志的內(nèi)容一致，但在多事務(wù)的情況下，卻不能保證兩者的提交順序一致，比如下面這個(gè)例子，假設(shè)現(xiàn)在有3個(gè)事務(wù)同時(shí)提交：

T1 (--prepare--binlog---------------------commit)
T2 (-----prepare-----binlog----commit)
T3 (--------prepare-------binlog------commit)

解析：

    redo log prepare的順序：T1 --》T2 --》T3

    binlog的寫(xiě)入順序：T1 --》 T2 --》T3

    redo log commit的順序：T2 --》 T3 --》T1

結(jié)論：由于binlog寫(xiě)入的順序和redo log提交結(jié)束的順序不一致，導(dǎo)致binlog和redo log所記錄的事務(wù)提交結(jié)束的順序不一樣，最終導(dǎo)致的結(jié)果就是主從數(shù)據(jù)不一致。

因此，在兩階段提交的流程基礎(chǔ)上，還需要加一個(gè)鎖來(lái)保證提交的原子性，從而保證多事務(wù)的情況下，兩個(gè)日志的提交順序一致。所以在早期的MySQL版本中，通過(guò)使用prepare_commit_mutex鎖來(lái)保證事務(wù)提交的順序，在一個(gè)事務(wù)獲取到鎖時(shí)才能進(jìn)入prepare，一直到commit結(jié)束才能釋放鎖，下個(gè)事務(wù)才可以繼續(xù)進(jìn)行prepare操作。通過(guò)加鎖雖然完美地解決了順序一致性的問(wèn)題，但在并發(fā)量較大的時(shí)候，就會(huì)導(dǎo)致對(duì)鎖的爭(zhēng)用，性能不佳。除了鎖的爭(zhēng)用會(huì)影響到性能之外，還有一個(gè)對(duì)性能影響更大的點(diǎn)，就是每個(gè)事務(wù)提交都會(huì)進(jìn)行兩次fsync（寫(xiě)磁盤(pán)），一次是redo log落盤(pán)，另一次是binlog落盤(pán)。大家都知道，寫(xiě)磁盤(pán)是昂貴的操作，對(duì)于普通磁盤(pán)，每秒的QPS大概也就是幾百。

五、組提交

問(wèn)題：針對(duì)通過(guò)在兩階段提交中加鎖控制事務(wù)提交順序這種實(shí)現(xiàn)方式遇到的性能瓶頸問(wèn)題，有沒(méi)有更好的解決方案呢？

答案自然是有的，在MySQL 5.6 就引入了binlog組提交，即BLGC（Binary Log Group Commit）。binlog組提交的基本思想是，引入隊(duì)列機(jī)制保證InnoDB commit順序與binlog落盤(pán)順序一致，并將事務(wù)分組，組內(nèi)的binlog刷盤(pán)動(dòng)作交給一個(gè)事務(wù)進(jìn)行，實(shí)現(xiàn)組提交目的。具體如圖：

第一階段（prepare階段）：

持有prepare_commit_mutex，并且write/fsync redo log到磁盤(pán)，設(shè)置為prepared狀態(tài)，完成后就釋放prepare_commit_mutex，binlog不作任何操作。

第二個(gè)階段（commit階段）：這里拆分成了三步，每一步的任務(wù)分配給一個(gè)專門的線程處理：

1. Flush Stage（寫(xiě)入binlog緩存）

   ① 持有Lock_log mutex [leader持有，follower等待]

   ② 獲取隊(duì)列中的一組binlog(隊(duì)列中的所有事務(wù))

   ③ 寫(xiě)入binlog緩存

2. Sync Stage（將binlog落盤(pán)）

   ①釋放Lock_log mutex，持有Lock_sync mutex[leader持有，follower等待]

   ②將一組binlog落盤(pán)（fsync動(dòng)作，最耗時(shí)，假設(shè)sync_binlog為1）。

3. Commit Stage（InnoDB commit，清楚undo信息）

   ①釋放Lock_sync mutex，持有Lock_commit mutex[leader持有，follower等待]

   ② 遍歷隊(duì)列中的事務(wù)，逐一進(jìn)行InnoDB commit

   ③ 釋放Lock_commit mutex

每個(gè)Stage都有自己的隊(duì)列，隊(duì)列中的第一個(gè)事務(wù)稱為leader，其他事務(wù)稱為follower，leader控制著follower的行為。每個(gè)隊(duì)列各自有mutex保護(hù)，隊(duì)列之間是順序的。只有flush完成后，才能進(jìn)入到sync階段的隊(duì)列中；sync完成后，才能進(jìn)入到commit階段的隊(duì)列中。但是這三個(gè)階段的作業(yè)是可以同時(shí)并發(fā)執(zhí)行的，即當(dāng)一組事務(wù)在進(jìn)行commit階段時(shí)，其他新事務(wù)可以進(jìn)行flush階段，實(shí)現(xiàn)了真正意義上的組提交，大幅度降低磁盤(pán)的IOPS消耗。

針對(duì)組提交為什么比兩階段提交加鎖性能更好，簡(jiǎn)單做個(gè)總結(jié)：組提交雖然在每個(gè)隊(duì)列中仍然保留了prepare_commit_mutex鎖，但是鎖的粒度變小了，變成了原來(lái)兩階段提交的1/4，所以鎖的爭(zhēng)用性也會(huì)大大降低；另外，組提交是批量刷盤(pán)，相比之前的單條記錄都要刷盤(pán)，能大幅度降低磁盤(pán)的IO消耗。

六、數(shù)據(jù)恢復(fù)流程

問(wèn)題：假設(shè)事務(wù)提交過(guò)程中，MySQL進(jìn)程突然奔潰，重啟后是怎么保證數(shù)據(jù)不丟失的？

下圖就是MySQL重啟后，提供服務(wù)前會(huì)先做的事 -- 恢復(fù)數(shù)據(jù)的流程：

對(duì)上圖進(jìn)行簡(jiǎn)單描述就是：奔潰重啟后會(huì)檢查redo log中是完整并且處于prepare狀態(tài)的事務(wù)，然后根據(jù)XID（事務(wù)ID），從binlog中找到對(duì)應(yīng)的事務(wù)，如果找不到，則回滾；找到并且事務(wù)完整則重新commit redo log，完成事務(wù)的提交。

下面我們根據(jù)事務(wù)提交流程，在不同的階段時(shí)刻，看看MySQL突然奔潰后，按照上述流程是如何恢復(fù)數(shù)據(jù)的。

1. 時(shí)刻A（剛在內(nèi)存中更改完數(shù)據(jù)頁(yè)，還沒(méi)有開(kāi)始寫(xiě)redo log的時(shí)候奔潰）：

   因?yàn)閮?nèi)存中的臟頁(yè)還沒(méi)刷盤(pán)，也沒(méi)有寫(xiě)redo log和binlog，即這個(gè)事務(wù)還沒(méi)有開(kāi)始提交，所以奔潰恢復(fù)跟該事務(wù)沒(méi)有關(guān)系；

2. 時(shí)刻B（正在寫(xiě)redo log或者已經(jīng)寫(xiě)完redo log并且落盤(pán)后，處于prepare狀態(tài)，還沒(méi)有開(kāi)始寫(xiě)binlog的時(shí)候奔潰）：

   恢復(fù)后會(huì)判斷redo log的事務(wù)是不是完整的，如果不是則根據(jù)undo log回滾；如果是完整的并且是prepare狀態(tài)，則進(jìn)一步判斷對(duì)應(yīng)的事務(wù)binlog是不是完整的，如果不完整則一樣根據(jù)undo log進(jìn)行回滾；

3. 時(shí)刻C（正在寫(xiě)binlog或者已經(jīng)寫(xiě)完binlog并且落盤(pán)了，還沒(méi)有開(kāi)始commit redo log的時(shí)候奔潰）：

   恢復(fù)后會(huì)跟時(shí)刻B一樣，先檢查redo log中是完整并且處于prepare狀態(tài)的事務(wù)，然后判斷對(duì)應(yīng)的事務(wù)binlog是不是完整的，如果不完整則一樣根據(jù)undo log回滾，完整則重新commit redo log；

4. 時(shí)刻D（正在commit redo log或者事務(wù)已經(jīng)提交完的時(shí)候，還沒(méi)有反饋成功給客戶端的時(shí)候奔潰）：

   恢復(fù)后跟時(shí)刻C基本一樣，都會(huì)對(duì)照redo log和binlog的事務(wù)完整性，來(lái)確認(rèn)是回滾還是重新提交。

七、總結(jié)

至此對(duì)MySQL 的crash-safe原理細(xì)節(jié)就基本講完了，簡(jiǎn)單回顧一下：

1. 首先簡(jiǎn)單介紹了WAL日志先行技術(shù)，包括它的定義、流程和作用。WAL是大部分?jǐn)?shù)據(jù)庫(kù)系統(tǒng)實(shí)現(xiàn)一致性和持久性的通用設(shè)計(jì)模式。；

2. 接著對(duì)MySQL的日志模塊，redo log、undo log、binlog、兩階段提交和組提交都進(jìn)行了詳細(xì)介紹；

3. 最后講解了數(shù)據(jù)恢復(fù)流程，并從不同時(shí)刻加以驗(yàn)證。

感謝各位的閱讀，以上就是“MySQL的crash-safe原理是什么”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)MySQL的crash-safe原理是什么這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！