[[408450]]

本文轉(zhuǎn)載自微信公眾號「飛天小牛肉」，作者飛天小牛肉。轉(zhuǎn)載本文請聯(lián)系飛天小牛肉公眾號。

前段時間我在準備暑期實習嘛，這是當時面攜程的時候二面的一道問題，我一臉懵逼，趕緊道歉，不好意思不知道沒了解過，面試官又解釋說 redo log，我尋思著 redo log 我知道啊，WAL 是啥?給面試官整無語了(滑稽)，為我當時的無知道歉。后來回去百度了一下才知道，最近又在丁奇大佬的《MySQL 實戰(zhàn) 45 講》 中看到了 WAL，遂來寫篇文章總結(jié)下。

InnoDB 體系架構(gòu)

在說 WAL 之前，有必要簡單介紹下 InnoDB 存儲引擎的體系架構(gòu)，方便我們理解下文，并且 redo log 也是 InnoDB 存儲引擎所特有的。

如下圖，InnoDB 存儲引擎由內(nèi)存池和一些后臺線程組成：

內(nèi)存池

先來解釋下內(nèi)存池。

首先，我們需要知道，InnoDB 存儲引擎是基于磁盤存儲的，并將其中的記錄按照頁的方式進行管理。因此可將其視為基于磁盤的數(shù)據(jù)庫系統(tǒng)(Disk-base Database)，在這樣的系統(tǒng)中，眾所周知，由于 CPU 速度與磁盤速度之間的不匹配，通常會使用緩沖池技術(shù)來提高數(shù)據(jù)庫的整體性能。

所以這里的內(nèi)存池也被稱為緩沖池(簡單理解為緩存就好了)。

具體來說，緩沖池其實就是一塊內(nèi)存區(qū)域，在 CPU 與磁盤之間加入內(nèi)存訪問，通過內(nèi)存的速度來彌補磁盤速度較慢對數(shù)據(jù)庫性能的影響。

擁有了緩沖池后，“讀取頁” 操作的具體步驟就是這樣的：

• 首先將從磁盤讀到的頁存放在緩沖池中
• 下一次再讀相同的頁時，首先判斷該頁是否在緩沖池中。若在緩沖池中，稱該頁在緩沖池中被命中，直接讀取該頁。否則，讀取磁盤上的頁。

“修改頁” 操作的具體步驟就是這樣的：

首先修改在緩沖池中的頁;然后再以一定的頻率刷新到磁盤上。

所謂 ”臟頁“ 就發(fā)生在修改這個操作中，如果緩沖池中的頁已經(jīng)被修改了，但是還沒有刷新到磁盤上，那么我們就稱緩沖池中的這頁是 ”臟頁“，即緩沖池中的頁的版本要比磁盤的新。

至此，綜上所述，我們可以得出這樣的結(jié)論：緩沖池的大小直接影響著數(shù)據(jù)庫的整體性能。

后臺線程

后臺線程其實最大的作用就是用來完成 “將從磁盤讀到的頁存放在緩沖池中” 以及 “將緩沖池中的數(shù)據(jù)以一定的頻率刷新到磁盤上” 這倆個操作的，當然了，還有其他的作用。以下是《MySQL 技術(shù)內(nèi)幕：InnoDB 存儲引擎 - 第 2 版》對于后臺線程的描述：

后臺線程的主要作用就是刷新內(nèi)存池中的數(shù)據(jù)，保證內(nèi)存池中緩存的是最近的數(shù)據(jù);此外將已修改的數(shù)據(jù)文件刷新到磁盤文件，同時保證在數(shù)據(jù)庫發(fā)生異常的情況下 InnoDB 能恢復到正常運行狀態(tài)。

另外，InnoDB 存儲引擎是多線程的模型，也就是說它擁有多個不同的后臺線程，負責處理不同的任務(wù)。這里簡單列舉下幾種不同的后臺線程：

• Master Thread：主要負責將緩沖池中的數(shù)據(jù)異步刷新到磁盤，保證數(shù)據(jù)的一致性
• IO Thread：在 InnoDB 存儲引擎中大量使用了 AIO(Async IO)來處理寫 IO 請求，這樣可以極大提高數(shù)據(jù)庫的性能。IO Thread 的工作主要是負責這些 IO 請求的回調(diào)(call back)處理
• Purge Thread：回收已經(jīng)使用并分配的 undo 頁
• Page Cleaner Thread：將之前版本中臟頁的刷新操作都放入到單獨的線程中來完成。其目的是為了減輕原 Master Thread 的工作及對于用戶查詢線程的阻塞，進一步提高 InnoDB 存儲引擎的性能

redo log 與 WAL 策略

上文我們提到，當緩沖池中的某頁數(shù)據(jù)被修改后，該頁就被標記為 ”臟頁“，臟頁的數(shù)據(jù)會被定期刷新到磁盤上。

倘若每次一個頁發(fā)生變化，就將新頁的版本刷新到磁盤，那么這個開銷是非常大的。并且，如果熱點數(shù)據(jù)都集中在某幾個頁中，那么數(shù)據(jù)庫的性能將變得非常差。另外，如果在從緩沖池將頁的新版本刷新到磁盤時發(fā)生了宕機，那么這個數(shù)據(jù)就不能恢復了。

所以，為了避免發(fā)生數(shù)據(jù)丟失的問題，當前事務(wù)數(shù)據(jù)庫系統(tǒng)(并非 MySQL 所獨有)普遍都采用了 WAL(Write Ahead Log，預寫日志)策略：即當事務(wù)提交時，先寫重做日志(redo log)，再修改頁(先修改緩沖池，再刷新到磁盤);當由于發(fā)生宕機而導致數(shù)據(jù)丟失時，通過 redo log 來完成數(shù)據(jù)的恢復。這也是事務(wù) ACID 中 D(Durability 持久性)的要求。

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

舉個簡單的例子，假設(shè)你非常熱心且 rich 的，借出去了很多錢，但是你非常 old school，不會使用電子設(shè)備并且記性不太好，所以你用一個小本本記下了所有欠你錢的人的名字和具體金額。這樣，別人還你錢的時候，你就翻出你的小本本，一頁頁地找到他的名字然后把這次還的錢扣除掉。

但是呢，其實你平常是非常忙碌的，沒辦法隨時隨地翻小本本做記錄，因此你就想出了一個主意：每當有人還你錢的時候，你就在一張白紙上記下來，然后挑個時間對照小本本把白紙上的賬目都給清了。

這就是 WAL。白紙就是 redo log，小本本就是磁盤。

當然了，redo log 可不是白紙這么簡單，一張用完了換一張就行了，這里有必要詳細解釋下。

每個 InnoDB 存儲引擎至少有 1 個重做日志文件組( redo log group)，每個文件組下至少有 2 個重做日志文件(redo log file)，默認的話是一個 redo log group，其中包含 2 個 redo log file：ib_logfile0 和 ib_logfile1 。

一般來說，為了得到更高的可靠性，用戶可以設(shè)置多個鏡像日志組(mirrored log groups)，將不同的文件組放在不同的磁盤上，以此提高 redo log 的高可用性。在日志組中每個 redo log file 的大小一致，并以循環(huán)寫入的方式運行。

所謂循環(huán)寫入，也就是為啥我們說 redo log 不像白紙那樣用完一張換一張就行，舉個例子，如下圖，一個 redo log group，包含 3 個 redo log file：

InnoDB 存儲引擎會先寫 redo log file 0，當 file 0 被寫滿的時候，會切換至 redo log file 1，當 file 1 也被寫滿時，會切換到 redo log file 2 中，而當 file 2 也被寫滿時，會再切換到 file 0 中。

可以看出，redo log file 的大小設(shè)置對于 InnoDB 存儲引擎的性能有著非常大的影響：

• redo log file 不能設(shè)置得太大，如果設(shè)置得很大，在恢復時可能需要很長的時間
• redo log file 又不能設(shè)置得太小了，否則可能導致一個事務(wù)的日志需要多次切換重做日志文件

CheckPoint 技術(shù)

有了 redo log 就可以高枕無憂了嗎?顯然不是這么簡單，我們?nèi)匀幻媾R這樣 3 個問題：

1)緩沖池不是無限大的，也就是說不能沒完沒了的存儲我們的數(shù)據(jù)等待一起刷新到磁盤

2)redo log 是循環(huán)使用而不是無限大的(也許可以，但是成本太高，同時不便于運維)，那么當所有的 redo log file 都寫滿了怎么辦?

3)當數(shù)據(jù)庫運行了幾個月甚至幾年時，這時如果發(fā)生宕機，重新應(yīng)用 redo log 的時間會非常久，此時恢復的代價將會非常大。

因此 Checkpoint 技術(shù)的目的就是解決上述問題：

• 緩沖池不夠用時，將臟頁刷新到磁盤
• redo log 不可用時，將臟頁刷新到磁盤
• 縮短數(shù)據(jù)庫的恢復時間

所謂 CheckPoint 技術(shù)簡單來說其實就是在 redo log file 中找到一個位置，將這個位置前的頁都刷新到磁盤中去，這個位置就稱為 CheckPoint(檢查點)。

針對上面這三點我們依次來解釋下：

1)縮短數(shù)據(jù)庫的恢復時間：當數(shù)據(jù)庫發(fā)生宕機時，數(shù)據(jù)庫不需要重做所有的日志，因為 Checkpoint 之前的頁都已經(jīng)刷新回磁盤。故數(shù)據(jù)庫只需對 Checkpoint 后的 redo log 進行恢復就行了。這顯然大大縮短了恢復的時間。

2)緩沖池不夠用時，將臟頁刷新到磁盤：所謂緩沖池不夠用的意思就是緩沖池的空間無法存放新讀取到的頁，這個時候 InnoDB 引擎會怎么辦呢?LRU 算法。InnoDB 存儲引擎對傳統(tǒng)的 LRU 算法做了一些優(yōu)化，用其來管理緩沖池這塊空間。

總的思路還是傳統(tǒng) LRU 那套，具體的優(yōu)化細節(jié)這里就不再贅述了：即最頻繁使用的頁在 LRU 列表(LRU List)的前端，最少使用的頁在 LRU 列表的尾端;當緩沖池的空間無法存放新讀取到的頁時，將首先釋放 LRU 列表中尾端的頁。這個被釋放出來(溢出)的頁，如果是臟頁，那么就需要強制執(zhí)行 CheckPoint，將臟頁刷新到磁盤中去。

3)redo log 不可用時，將臟頁刷新到磁盤：

所謂 redo log 不可用就是所有的 redo log file 都寫滿了。但事實上，其實 redo log 中的數(shù)據(jù)并不是時時刻刻都是有用的，那些已經(jīng)不再需要的部分就稱為 ”可以被重用的部分“，即當數(shù)據(jù)庫發(fā)生宕機時，數(shù)據(jù)庫恢復操作不需要這部分的 redo log，因此這部分就可以被覆蓋重用(或者說被擦除)。

舉個例子來具體解釋下：一組 4 個文件，每個文件的大小是 1GB，那么總共就有 4GB 的 redo log file 空間。write pos 是當前 redo log 記錄的位置，隨著不斷地寫入磁盤，write pos 也不斷地往后移，就像我們上文說的，寫到 file 3 末尾后就回到 file 0 開頭。CheckPoint 是當前要擦除的位置(將 Checkpoint 之前的頁刷新回磁盤)，也是往后推移并且循環(huán)的：

write pos 和 CheckPoint 之間的就是 redo log file 上還空著的部分，可以用來記錄新的操作。如果 write pos 追上 CheckPoint，就表示 redo log file 滿了，這時候不能再執(zhí)行新的更新，得停下來先覆蓋(擦掉)一些 redo log，把 CheckPoint 推進一下。

綜上所述，Checkpoint 所做的事情無外乎是將緩沖池中的臟頁刷新到磁盤。不同之處在于每次刷新多少頁到磁盤，每次從哪里取臟頁，以及什么時間觸發(fā) Checkpoint。在 InnoDB 存儲引擎內(nèi)部，有兩種 Checkpoint，分別為：

• Sharp Checkpoint：發(fā)生在數(shù)據(jù)庫關(guān)閉時將所有的臟頁都刷新回磁盤，這是默認的工作方式，參數(shù) innodb_fast_shutdown=1
• Fuzzy Checkpoin：InnoDB 存儲引擎內(nèi)部使用這種模式，只刷新一部分臟頁，而不是刷新所有的臟頁回磁盤。關(guān)于 Fuzzy CheckPoint 具體的情況這里就不再贅述了。

有了 bin log 為什么還需要 redo log?

前文我們講過，MySQL 架構(gòu)可以分成倆層，一層是 Server 層，它主要做的是 MySQL 功能層面的事情;另一層就是存儲引擎，負責存儲與提取相關(guān)的具體事宜。

redo log 是 InnoDB 引擎特有的日志，而 Server 層也有自己的日志，包括錯誤日志(error log)、二進制日志(binlog)、慢查詢?nèi)罩?slow query log)、查詢?nèi)罩?log)。

其他三個日志顧明思意都挺好理解的，需要解釋的就是 binlog(二進制日志，binary log)，它記錄了對 MySQL 數(shù)據(jù)庫執(zhí)行更改的所有操作，但是不包括 SELECT 和 SHOW 這類操作，因為這類操作對數(shù)據(jù)本身并沒有修改。也就是說，binlog 是邏輯日志，記錄的是這個語句的原始邏輯，比如 “給 ID=1 這一行的 a 字段加 1”。

可以看出來，binlog 日志只能用于歸檔，因此 binlog 也被稱為歸檔日志，顯然如果 MySQL 只依靠 binlog 等這四種日志是沒有 crash-safe 能力的，所以為了彌補這種先天的不足，得益于 MySQL 可插拔的存儲引擎架構(gòu)，InnoDB 開發(fā)了另外一套日志系統(tǒng) — 也就是 redo log 來實現(xiàn) crash-safe 能力。

這就是為什么有了 bin log 為什么還需要 redo log 的答案。

回顧下 redo log 存儲的東西，可以發(fā)現(xiàn) redo log 是物理日志，記錄的是 “在某個數(shù)據(jù)頁上做了什么修改”。

另外，還有一點不同的是：binlog 是追加寫入的，就是說 binlog 文件寫到一定大小后會切換到下一個，并不會覆蓋以前的日志;而 redo log 是循環(huán)寫入的。