目錄redo log介紹redo log整體流程redo log落盤策略redo log寫入數據頁機制總結redo log介紹

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

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

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

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

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

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

redo log整體流程

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

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

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

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

redo log落盤策略

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

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

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

innodb_flush_log_at_trx_commit=1

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

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

innodb_flush_log_at_trx_commit=2

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

為0時，后臺線程每隔1秒進行一次重做日志的刷盤操作，因此MySQL掛了最多丟失1秒鐘內的事務。這種方式效率是最高的，這種策略也有丟失數據的風險，也無法保證持久性。其他被動觸發刷盤的場景

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

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

小結：

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

redo log寫入數據頁機制

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

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

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

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

這就是整個redo log file中的日志恢復到數據頁中的過程。

總結

本文講解了事務日志redo log在MySQL innoDB存儲引擎工作的機制，它主要是用來保證事務的持久性，避免數據丟失。如果本文對你有幫助，請留下一個贊。

到此這篇關于詳解MySQL事務日志redo log的文章就介紹到這了,更多相關MySQL事務日志redo log內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！