詳解MySQL事務日志redo log

更新時間：2023年07月14日 11:08:58 作者：JAVA旭陽

你知道MySQL 中是如何保證數(shù)據(jù)不丟失的嗎，即便是MySQL發(fā)生異常重啟了，數(shù)據(jù)也可以恢復，你了解MySQL產(chǎn)生的事務日志redo log是干嘛的嗎，明白它的工作機制嗎，本文就給大家詳細講解MySQL事務日志redo log

redo log介紹

redo log又叫“重做日志”,是存儲引擎層 (innoDB) 生成的日志，記錄的是"物理級別"上的頁修改操作，比如頁號x，偏移量y寫入了'z'數(shù)據(jù)，主要目的為了保證數(shù)據(jù)不丟失，當MySQL發(fā)生宕機的時候，可以利用redo log日志進行數(shù)據(jù)恢復，如下圖所示。

默認的redo log日志文件為ib_logfile0, ib_logfile1，如下圖：

那想過為什么要"多此一舉"先寫入到redo log磁盤文件中，然后再落到數(shù)據(jù)庫表中？而不直接落到數(shù)據(jù)庫表中？

主要是因為順序IO性能遠高于隨機IO。

數(shù)據(jù)在MySQL中存儲是以頁為單位，事務中的數(shù)據(jù)可能遍布在不同的頁中，如果直接寫入到對應的頁中，是隨機IO寫入。

而redo log是通過順序IO"追加"的方式寫入到文件末尾，而且寫入的內(nèi)容也是物理日志，比如比如，某個事務將系統(tǒng)表空間中第10號頁面中偏移量為 100 處的那個字節(jié)的值 1 改成 2等信息，日志占用空間也很小。

redo log整體流程

事務在寫入到數(shù)據(jù)庫中涉及到redo log的整體流程如下圖所示：

性能不夠，緩存來湊。由于CPU的性能遠遠大于磁盤，為了消除這個鴻溝，引入了兩個緩存，Buffer Pool和redo log buffer。Buffer Pool用來存放各種操作，比如寫入數(shù)據(jù)時，先寫到內(nèi)存中，然后由后臺線程再刷寫到磁盤。redo log buffer用來存放重做日志，后續(xù)刷到磁盤中。

先將原始數(shù)據(jù)從磁盤中讀入到Buffer Pool中
修改Buffer Pool中的數(shù)據(jù)
生成一條重做日志并寫入redo log buffer，記錄數(shù)據(jù)修改后的值
當事務提交時，將redo log buffer中的內(nèi)容追加磁盤中的redo log文件中
將磁盤日志文件redo log file 內(nèi)容刷到數(shù)據(jù)庫表中

上面流程中這種先寫日志，再寫磁盤，只有日志寫入成功，才算事務提交成功的技術思想在MySQL也叫做WAL技術 (Write-Ahead Logging)。

redo log落盤策略

事務的日志是先寫入到redo log buffer 中是很快的，那如何保證redo log buffer中的信息高效的落到磁盤日志文件中呢？

redo log buffer不是直接將日志內(nèi)容刷盤到redo log file中。
redo log buffer內(nèi)容先刷入到操作系統(tǒng)的文件系統(tǒng)緩存（page cache）中去，這個過程很快，而且整個系統(tǒng)宕機概率相對MySQL會小很多。
最后，日志內(nèi)容會從操作系統(tǒng)的文件系統(tǒng)緩存中刷到磁盤的日志文件中，至于什么時候觸發(fā)這個動作，MySQL的innoDB引擎提供了3種策略可選。

InnoDB引擎提供了 innodb_flush_log_at_trx_commit 參數(shù)，該參數(shù)控制 commit提交事務時，如何將 redo log buffer 中的日志刷新到 redo log file 的3種策略。

innodb_flush_log_at_trx_commit=1

每次事務提交時都將進行同步, 執(zhí)行主動刷盤操作，如上圖的紅線位置，所以只要事務提交成功，redo log記錄就一定在硬盤里，不會有田可數(shù)據(jù)丟失。
該種方式是MySQL innoDB存儲引擎默認的刷盤機制。
如果事務執(zhí)行期間MySQL掛了或宕機，這部分日志丟了，但是事務并沒有提交，所以日志丟了也不會有損

失。可以保證ACID的D，數(shù)據(jù)絕對不會丟失，但是效率最差的。

innodb_flush_log_at_trx_commit=2

為2時，只要事務提交成功，redo log buffer中的內(nèi)容只寫入文件系統(tǒng)緩存（pagecache）
如果僅僅只是MySQL掛了不會有任何數(shù)據(jù)丟失，但是操作系統(tǒng)宕機可能會有1秒數(shù)據(jù)的丟失，這種情況下無法滿足ACID中的D
數(shù)值2的效率是高于數(shù)值等于1的

innodb_flush_log_at_trx_commit=0

為0時，后臺線程每隔1秒進行一次重做日志的刷盤操作，因此MySQL掛了最多丟失1秒鐘內(nèi)的事務。
這種方式效率是最高的，這種策略也有丟失數(shù)據(jù)的風險，也無法保證持久性。

其他被動觸發(fā)刷盤的場景

除了上面3種策略進行刷盤以外，還有兩種場景會讓一個沒有提交的事務的 redo log 寫入到磁盤中。

redo log buffer 占用的空間即將達到 innodb_log_buffer_size 一半的時候，后臺線程會主動寫盤。注意，由于這個事務并沒有提交，所以這個寫盤動作只是 write，而沒有調(diào)用 fsync，也就是只留在了文件系統(tǒng)的 page cache。
并行的事務提交的時候，順帶將這個事務的 redo log buffer 持久化到磁盤。假設一個事務 A 執(zhí)行到一半，已經(jīng)寫了一些 redo log 到 buffer 中，這時候有另外一個線程的事務 B 提交，如果 innodb_flush_log_at_trx_commit 設置的是 1，那么按照這個參數(shù)的邏輯，事務 B 要把 redo log buffer 里的日志全部持久化到磁盤。這時候，就會帶上事務 A 在 redo log buffer 里的日志一起持久化到磁盤。

小結(jié)：

我們可以根據(jù)實際的業(yè)務場景，在性能和持久性做一些權(quán)衡，但建議使用默認值，雖然操作系統(tǒng)宕機的概率理論小于數(shù)據(jù)庫宕機的概率，但是一般既然使用了事務，那么數(shù)據(jù)的安全相對來說更重要些。

redo log寫入數(shù)據(jù)頁機制

目前事務日志已經(jīng)落入到磁盤的redo log file中了，MySQL會去讀取這個文件將數(shù)據(jù)寫入到數(shù)據(jù)頁中。

很顯然，目前對redo log file會進行讀和寫的操作。在日志文件組中有兩個重要的“指針”，分別是 write pos、``checkpoint。

write pos是當前記錄的位置，一邊寫一邊后移
checkpoint是當前要擦除的位置，也是往后推移

每次刷盤 redo log 記錄到日志文件組中，write pos 位置就會后移更新。
每次MySQL加載日志文件組恢復數(shù)據(jù)時，會清空加載過的 redo log 記錄，并把checkpoint后移更新。
如果write pos 追上 checkpoint ，表示日志文件組滿了，這時候不能再寫入新的 redo log記錄，MySQL 得停下來，清空一些記錄，把 checkpoint 推進一下，如下圖：