概要

Redo Log和Binlog是MySQL日志系統(tǒng)中非常重要的兩種機制，也有很多相似之處，本文主要介紹兩者細節(jié)和區(qū)別。

Redo Log日志

Redo Log的作用

準備一張測試表

create table test_redo(id int primary key, c int);

假設(shè)現(xiàn)在要執(zhí)行這樣一條sql

update test_redo set c = c + 1 where id = 1;

修改一條數(shù)據(jù)，首先是修改了Buffer Pool中該條數(shù)據(jù)所在的數(shù)據(jù)頁。假如說我們剛提交了事務(wù)，發(fā)生了某個故障，內(nèi)存中的數(shù)據(jù)都失效了，就會導(dǎo)致所做的修改跟著丟失了。這是不能接受的。
如何避免這樣的情況發(fā)生？
一個簡單粗暴的做法是：在事務(wù)提交完成之前把該事務(wù)所修改的所有頁面都刷新到磁盤
這樣做有以下兩個問題：

1. 刷新一個完整的數(shù)據(jù)也太浪費
   比如上面只修改了一個字段，就要刷新整個頁（16KB），InnoDB是以頁為單位進行IO的，很浪費
2. 隨機IO速度很慢
   涉及到多個頁時，頁與頁之間在磁盤上可能是不連續(xù)的，隨機IO要比順序IO慢很多。

為了達到系統(tǒng)崩潰后，服務(wù)重啟也能恢復(fù)原來提交的事務(wù)修改的目的，同時避免出現(xiàn)上面提到的問題，Redo Log就是一種解決方案。

Redo Log，重做日志，其本質(zhì)是記錄?下事務(wù)對數(shù)據(jù)庫做了哪些修改：

將第0號表空間的100號頁面的偏移量為1處的值更新為2

具體來說，當有一條記錄需要更新的時候，InnoDB 引擎就會先把記錄寫到 Redo Log里面，并更新內(nèi)存，這個時候更新就算完成了。同時，InnoDB 引擎會在適當?shù)臅r候，將這個操作記錄更新到磁盤里面。

這就是 MySQL 里經(jīng)常說到的 WAL 技術(shù)，WAL 的全稱是 Write-Ahead Logging，它的關(guān)鍵點就是先寫日志，再寫磁盤。

通過事務(wù)執(zhí)行過程中產(chǎn)生的redo日志刷新到磁盤的方式，跟前面提到的簡單粗暴的方式比較，有如下好處：

• redo日志占用的空間非常少
• redo日志是順序?qū)懭氪疟P的

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

Redo Log的寫入機制

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

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

write pos 和 checkpoint 之間空著的部分，可以用來記錄新的操作。如果 write pos 追上 checkpoint，表示寫滿，這時候不能再執(zhí)行新的更新，把 checkpoint 推進一下。

可通過以下查詢redo log文件的數(shù)量跟大小

show variables like '%innodb_log_file%';

在服務(wù)器端可看到對應(yīng)的文件

redo log buffer

假如執(zhí)行如下sql

begin;
insert into t1 ...
insert into t2 ...
commit;

這個事務(wù)要往兩個表中插入記錄，插入數(shù)據(jù)的過程中，還沒有執(zhí)行 commit 的時候，不能直接寫到 redo log 文件里的。這時候會先記錄在redo log buffer
redo log buffer 就是一塊內(nèi)存，用來先存 redo 日志。也就是說，在執(zhí)行第一個 insert 的時候，數(shù)據(jù)的確發(fā)生了修改，redo log buffer 也寫入了日志。但是，真正把日志寫到 redo log 文件（文件名是 ib_logfile+ 數(shù)字），是在執(zhí)行 commit 語句的時候做的。

單獨執(zhí)行一個更新語句的時候，InnoDB 會自己啟動一個事務(wù)，在語句執(zhí)行完成的時候提交。過程跟上面是一樣的。

redo log buffer是什么時候持久化到Redo Log中的呢？有如下3種策略，可通過innodb_flush_log_at_trx_commit進行配置。它有3種取值：

1. 設(shè)置為 0 的時候，表示每次事務(wù)提交時都只是把 redo log 留在 redo log buffer 中，由后臺線程每隔1s執(zhí)行一次刷盤操作 ;
2. 設(shè)置為 1 的時候（默認值），表示每次事務(wù)提交時都將 redo log 直接持久化到磁盤；
3. 設(shè)置為 2 的時候，表示每次事務(wù)提交時都只是把 redo log 寫到 OS cache，然后由后臺Master線程再每隔1秒執(zhí)行OS
   cache -> flush cache to disk 的操作。

一般建議選擇取值2，因為 MySQL 掛了數(shù)據(jù)沒有損失，整個服務(wù)器掛了才會損失1秒的事務(wù)提交數(shù)據(jù)。設(shè)置為1時最為安全，但是性能也是最差。

Binlog日志

Binlog的作用

Redo Log 是屬于InnoDB引擎所特有的日志，而MySQL Server層也有自己的日志，即 Binary log（二進制日志），簡稱Binlog。Binlog是記錄所有數(shù)據(jù)庫表結(jié)構(gòu)變更以及表數(shù)據(jù)修改的二進制日志，不會記錄SELECT和SHOW這類操作。Binlog日志是以事件形式記錄，還包含語句所執(zhí)行的消耗時間。

最開始 MySQL 里并沒有 InnoDB 引擎。MySQL 自帶的引擎是 MyISAM，但是 MyISAM 沒有 crash-safe 能力，binlog 日志只能用于歸檔。而 InnoDB 是另一個公司以插件形式引入 MySQL 的，既然只依靠 binlog 是沒有 crash-safe 能力的，所以 InnoDB 使用另外一套日志系統(tǒng)——也就是 redo log 來實現(xiàn) crash-safe 能力。

Binlog日志有以下兩個最重要的應(yīng)用場景：

1. 主從復(fù)制：在主庫中開啟Binlog功能，這樣主庫就可以把Binlog傳遞給從庫，從庫拿到Binlog后實現(xiàn)數(shù)據(jù)恢復(fù)達到主從數(shù)據(jù)一致性。
2. 數(shù)據(jù)恢復(fù)：通過mysqlbinlog工具來恢復(fù)數(shù)據(jù)

Binlog日志文件記錄模式有STATEMENT、ROW和MIXED三種，具體含義如下。

• ROW（row-based replication, RBR）：日志中會記錄每一行數(shù)據(jù)被修改的情況，然后在slave端對相同的數(shù)據(jù)進行修改。
  優(yōu)點：能清楚記錄每一個行數(shù)據(jù)的修改細節(jié)，能完全實現(xiàn)主從數(shù)據(jù)同步和數(shù)據(jù)的恢復(fù)。
  缺點：批量操作，會產(chǎn)生大量的日志，尤其是alter table會讓日志暴漲。

• STATMENT（statement-based replication, SBR）：每一條被修改數(shù)據(jù)的SQL都會記錄到master的Binlog中，slave在復(fù)制的時候SQL進程會解析成和原來master端執(zhí)行過的相同的SQL再次執(zhí)行。簡稱SQL語句復(fù)制。
  優(yōu)點：日志量小，減少磁盤IO，提升存儲和恢復(fù)速度
  缺點：在某些情況下會導(dǎo)致主從數(shù)據(jù)不一致，比如last_insert_id()、now()等函數(shù)。

• MIXED（mixed-based replication, MBR）：以上兩種模式的混合使用，一般會使用STATEMENT模式保存binlog，對于STATEMENT模式無法復(fù)制的操作使用ROW模式保存binlog，MySQL會根據(jù)執(zhí)行的SQL語句選擇寫入模式。

可通過以下sql查看Binlog信息

show variables like '%log_bin%';
show variables like '%binlog%';

格式查看

mysql> show variables like 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
1 row in set (0.00 sec)

Biglog文件格式

MySQL的binlog文件中記錄的是對數(shù)據(jù)庫的各種修改操作，用來表示修改操作的數(shù)據(jù)結(jié)構(gòu)是Log event。不同的修改操作對應(yīng)的不同的log event。比較常用的log event有：Query event、Row event、Xid event等。binlog文件的內(nèi)容就是各種Log event的集合。
Binlog文件中Log event結(jié)構(gòu)如下圖所示：

查看當前的二進制日志文件列表及大小。指令如下：

mysql> SHOW BINARY LOGS;
+---------------+-----------+-----------+
| Log_name      | File_size | Encrypted |
+---------------+-----------+-----------+
| binlog.000004 |    712684 | No        |
| binlog.000005 |       179 | No        |
| binlog.000006 |       179 | No        |
| binlog.000007 |   3412930 | No        |
+---------------+-----------+-----------+
4 rows in set (0.00 sec)

查看具體的文件
語法：show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];

-- 文件內(nèi)容太多了 這里限制了從 pos 156開始查看 限制5條
mysql> show binlog events in 'binlog.000004' from 156 limit 5 \G;
*************************** 1. row ***************************Log_name: binlog.000004Pos: 156Event_type: Anonymous_GtidServer_id: 1
End_log_pos: 235Info: SET @@SESSION.GTID_NEXT= 'ANONYMOUS'
*************************** 2. row ***************************Log_name: binlog.000004Pos: 235Event_type: QueryServer_id: 1
End_log_pos: 317Info: BEGIN
*************************** 3. row ***************************Log_name: binlog.000004Pos: 317Event_type: Table_mapServer_id: 1
End_log_pos: 402Info: table_id: 92 (small_admin.QRTZ_CRON_TRIGGERS)
*************************** 4. row ***************************Log_name: binlog.000004Pos: 402Event_type: Delete_rowsServer_id: 1
End_log_pos: 502Info: table_id: 92 flags: STMT_END_F
*************************** 5. row ***************************Log_name: binlog.000004Pos: 502Event_type: XidServer_id: 1
End_log_pos: 533Info: COMMIT /* xid=392 */
5 rows in set (0.00 sec)

binlog是二進制文件，無法直接查看，借助mysqlbinlog命令工具了，可以查看其中的內(nèi)容

# mysqlbinlog使用語法 
[root@node1 data]# mysqlbinlog --no-defaults --help

查看文件

mysqlbinlog --no-defaults --base64-output=decode-rows -vv binlog.000004 |tail -100

Binlog寫入機制

事務(wù)執(zhí)行過程中，先把日志寫到 binlog cache，事務(wù)提交的時候，再把 binlog cache 寫到 binlog 文件中。

一個事務(wù)的 binlog 是不能被拆開的，因此不論這個事務(wù)多大，也要確保一次性寫入。這就涉及到了 binlog cache 的保存問題。

系統(tǒng)給 binlog cache 分配了一片內(nèi)存，每個線程一個，參數(shù) binlog_cache_size 用于控制單個線程內(nèi) binlog cache 所占內(nèi)存的大小。如果超過了這個參數(shù)規(guī)定的大小，就要暫存到磁盤。

事務(wù)提交的時候，執(zhí)行器把 binlog cache 里的完整事務(wù)寫入到 binlog 中，并清空 binlog cache。

write 和 fsync 的時機，是由參數(shù) sync_binlog 控制的：

1. sync_binlog=0 的時候，表示每次提交事務(wù)都只 write，不 fsync；
2. sync_binlog=1 的時候，表示每次提交事務(wù)都會執(zhí)行 fsync；
3. sync_binlog=N(N>1) 的時候，表示每次提交事務(wù)都 write，但累積 N 個事務(wù)后才 fsync。

因此，在出現(xiàn) IO 瓶頸的場景里，將 sync_binlog 設(shè)置成一個比較大的值，可以提升性能。在實際的業(yè)務(wù)場景中，考慮到丟失日志量的可控性，一般不建議將這個參數(shù)設(shè)成 0，比較常見的是將其設(shè)置為 100~1000 中的某個數(shù)值。

但是，將 sync_binlog 設(shè)置為 N，對應(yīng)的風險是：如果主機發(fā)生異常重啟，會丟失最近 N 個事務(wù)的 binlog 日志。

兩段提交

結(jié)合redo log 跟bin log ，執(zhí)行update test_redo set c = c + 1 where id = 1 這條語句的大致過程如下：

1. 執(zhí)行器先找引擎取 id=1 這一行。id 是主鍵，引擎直接用樹搜索找到這一行。如果 id=1 這一行所在的數(shù)據(jù)頁本來就在內(nèi)存中，就直接返回給執(zhí)行器；否則，需要先從磁盤讀入內(nèi)存，然后再返回。
2. 執(zhí)行器拿到引擎給的行數(shù)據(jù)，把c的值加 1，比如原來是 N，現(xiàn)在就是 N+1，得到新的一行數(shù)據(jù)，再調(diào)用引擎接口寫入這行新數(shù)據(jù)。
3. 引擎將這行新數(shù)據(jù)更新到內(nèi)存中，同時將這個更新操作記錄到 redo log 里面，此時 redo log 處于 prepare 狀態(tài)。然后告知執(zhí)行器執(zhí)行完成了，隨時可以提交事務(wù)。
4. 執(zhí)行器生成這個操作的 binlog，并把 binlog 寫入磁盤。
5. 執(zhí)行器調(diào)用引擎的提交事務(wù)接口，引擎把剛剛寫入的 redo log 改成提交（commit）狀態(tài)，更新完成。

Q：為什么需要兩段提交？

A：用上面的更新語句作為例子
如果不用兩階段提交，要么就是先寫完 redo log 再寫 binlog，或者是先寫binlog再寫redo log，下面對這兩種情況討論

1. 先寫 redo log 后寫 binlog。假設(shè)在 redo log 寫完，binlog 還沒有寫完時MySQL 進程異常重啟。由于redo log 寫完后，系統(tǒng)即使崩潰，仍然能夠把數(shù)據(jù)恢復(fù)回來，所以恢復(fù)后這一行 c 的值是 1。 但是由于 binlog 沒寫完， binlog 里面就沒有記錄這條語句。因此，之后備份日志的時候用這個 binlog 來恢復(fù)臨時庫的話，就會與原庫的值有差異。
2. 先寫 binlog 后寫 redo log。如果在 binlog 寫完之后 crash，由于 redo log 還沒寫，崩潰恢復(fù)以后這個事務(wù)無效，所以這一行 c 的值是 0。但是 binlog 里面已經(jīng)記錄了“把 c 從 0 改成 1”這個日志。在之后用 binlog 來恢復(fù)的時候就會與原庫有差異。

Q：上圖中，如果在時刻A，也就是寫入 redo log 處于 prepare 階段之后、寫 binlog 之前，發(fā)生了奔潰呢？
A：由于此時 binlog 還沒寫，redo log 也還沒提交，所以崩潰恢復(fù)的時候，這個事務(wù)會回滾。這時候，binlog 還沒寫，所以也不會傳到備庫

Q：如果在B時刻，也就是 binlog 寫完，redo log 還沒 commit 前發(fā)生 crash，那崩潰恢復(fù)的時候 MySQL 會怎么處理？
A：崩潰恢復(fù)時的判斷如下

1. 如果 redo log 里面的事務(wù)是完整的，也就是已經(jīng)有了 commit 標識，則直接提交；
2. 如果 redo log 里面的事務(wù)只有完整的 prepare，則判斷對應(yīng)的事務(wù) binlog 是否存在并完整： a. 如果是，則提交事務(wù)； b. 否則，回滾事務(wù)。

Q：redo log 和 binlog 是怎么關(guān)聯(lián)起來的?
A：它們有一個共同的數(shù)據(jù)字段，叫 XID。崩潰恢復(fù)的時候，會按順序掃描 redo log：
如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；
如果碰到只有 parepare、而沒有 commit 的 redo log，就拿著 XID 去 binlog 找對應(yīng)的事務(wù)。