讀這篇文章前，可以先看看前文 MySQL——update 語(yǔ)句執(zhí)行流程，以便對(duì)整體有個(gè)大概的了解。

一、重做日志（redo log）

InnoDB 存儲(chǔ)引擎會(huì)使用重做日志文件恢復(fù)到掉電前的時(shí)刻，以此來(lái)保證數(shù)據(jù)的完整性。

redo log 是物理日志，記錄的是“在某個(gè)數(shù)據(jù)頁(yè)上做了什么修改”；

• 采用 WAL（Write Ahead Log）策略，事務(wù)提交時(shí)，先寫(xiě)重做日志再修改頁(yè)；
• 每個(gè) InnoDB 存儲(chǔ)引擎至少有 1 個(gè)重做日志文件組（group），每個(gè)文件組下至少有 2 個(gè)重做日志文件（如默認(rèn)的 ib_logfile0 和 ib_logfile1）；
• 可以設(shè)置多個(gè)鏡像日志組，將不同的文件組放在不同磁盤(pán)上，以提高重做日志的高可用性；
• 在日志組中每個(gè)重做日志文件大小一致，并以循環(huán)寫(xiě)入的方式運(yùn)行；

表1 重做日志文件參數(shù)

下圖 1 以一個(gè)重做日志文件組中有四個(gè)重做日志文件為例，每個(gè)日志文件大小最大只能 512GB。

圖1 redo log 文件結(jié)構(gòu)圖

• 重做日志文件設(shè)置過(guò)大 —— 恢復(fù)時(shí)間長(zhǎng)。
• 重做日志文件設(shè)置過(guò)小 —— 可能導(dǎo)致一個(gè)事務(wù)的日志需要多次切換重做日志文件。且會(huì)導(dǎo)致頻繁地發(fā)生 async checkpoint，導(dǎo)致性能的抖動(dòng)。

重做日志文件組

在每個(gè)組的第一個(gè)redo log file中，前四個(gè)塊記錄特定部分（2KB），之后才開(kāi)始記錄 log block。除了第一個(gè) redo log file 中會(huì)記錄，log group 中的其他 log file 不會(huì)記錄這2KB，但是卻會(huì)騰出這 2KB 的空間。

圖2 redo log 寫(xiě)入過(guò)程

圖2 redo log 寫(xiě)入過(guò)程

重做日志緩沖（內(nèi)存中）寫(xiě)入磁盤(pán)的重做日志文件時(shí)，按 512 字節(jié)（一個(gè)扇區(qū)大?。?，因?yàn)樯葏^(qū)是寫(xiě)入的最小單位，因此可以保證寫(xiě)入必定是成功的。因此在重做日志的寫(xiě)入過(guò)程中不需要有 doublewrite。

重做日志格式

在 InnoDB 存儲(chǔ)引擎中，對(duì)于各種不同的操作有著不同的重做日志格式。到 InooDB 1.2.x 版本為止，總共定義了 51 種重做日志類型（例如下圖3 insert 語(yǔ)句和 delete 語(yǔ)句寫(xiě)入 redo_log_body 內(nèi)容是不一樣的）。雖然各種重做日志類型不同，但是它們有著基本的格式，下表 2 顯示了重做日志條目的結(jié)構(gòu)。

表2 重做日志條目結(jié)構(gòu)

圖3 不同重做日志格式

可以從上表 2 中看到，重做日志由 4 部分組成。

表3 重做日志條目結(jié)構(gòu)解釋

表空間ID + 頁(yè)號(hào) 即可唯一定位需要進(jìn)行修改的頁(yè)。

重做日志塊

redo log 是基于頁(yè)的格式來(lái)記錄的，innodb 的頁(yè)大小默認(rèn)是16KB(由 innodb_page_size變量控制)，一個(gè)頁(yè)中可以存放多個(gè) redo log block 重做日志塊（512B），

圖4 重做日志塊

redo log恢復(fù)

假如數(shù)據(jù)在 LSN:10 000 的時(shí)候宕機(jī)了，則恢復(fù) LSN：10 000 到 LSN：13 000 范圍的日志，因?yàn)榇藭r(shí) CP 的 LSN 為 10 000。

圖5 重做日志數(shù)據(jù)恢復(fù)

刷盤(pán)時(shí)機(jī)

重做日志寫(xiě)入重做日志文件觸發(fā)條件:

1. 主線程中每秒會(huì)將重做日志緩沖寫(xiě)入磁盤(pán)的重做日文件中，不論事務(wù)是否提交。
2. 參數(shù) innodb_flush_log_at_trx_commit 控制，表示在提交（commit）操作時(shí)，處理重做日志的方式。
3. 當(dāng)重做日志緩沖池剩余空間小于1/2時(shí)，重做日志刷新到重做日志文件。

引發(fā)數(shù)據(jù)庫(kù)刷臟頁(yè)（flush）過(guò)程的情況：

1. InnoDB 的 redo log 寫(xiě)滿時(shí)，系統(tǒng)會(huì)停止所有的更新操作，把 checkpoint 往前推進(jìn)（如圖1），redo log 留出空間繼續(xù)寫(xiě)。
2. 系統(tǒng)內(nèi)存不足時(shí)，淘汰一些數(shù)據(jù)頁(yè)，如果是臟頁(yè)則先刷到磁盤(pán)。
3. MySQL 認(rèn)為系統(tǒng) ”空閑“ 時(shí)，只要有機(jī)會(huì)就刷一點(diǎn) ”臟頁(yè)“。
4. MySQL 正常關(guān)閉時(shí)，MySQL 會(huì)把內(nèi)存的臟頁(yè)都 flush 到磁盤(pán)上。

二、二進(jìn)制日志（binlog）

binlog 是邏輯日志，記錄的是這個(gè)語(yǔ)句的原始邏輯，比如“給ID=2這一行的c字段加1 ”。

其有以下三大模式。

參數(shù)設(shè)置： binlog_format

Statement，基于 SQL 語(yǔ)句復(fù)制(statement-based replication, SBR)（默認(rèn)）

• 二進(jìn)制文件記錄的是日志的邏輯 SQL 語(yǔ)句。
• 優(yōu)點(diǎn)：不需要記錄每一條 SQL 語(yǔ)句與每行的數(shù)據(jù)變化，這樣子 binlog 的日志也會(huì)比較少，減少了磁盤(pán)IO，提高性能。
• 缺點(diǎn)：在某些情況下會(huì)導(dǎo)致 master-slave 中的數(shù)據(jù)不一致。

ROW，基于行復(fù)制（row-based replication, RBR）

• 不只是記錄簡(jiǎn)單的 SQL 語(yǔ)句，而是記錄表的更改情況。
• 優(yōu)點(diǎn)：只需要記錄被修改的

Mixed，混合模式復(fù)制（mixed-based replication, MBR）

三、redo log 與 binlog 的區(qū)別

表4 redo log 與 binlog 的區(qū)別

• redo log 是物理日志，記錄的是“在某個(gè)數(shù)據(jù)頁(yè)上做了什么修改”；
• binlog 是邏輯日志，記錄的是這個(gè)語(yǔ)句的原始邏輯，比如“給ID=2這一行的c字段加1 ”。

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。