MySQL重做日誌（redo log）

2020 年 12 月 5 日
筆記
MySQL

前面介紹了三種日誌：error log、slow log、binlog，這三種都是 Server 層的。今天的 redo log 是 InnoDB引擎專有的日誌文件。

為什麼要有 redo log

用個酒店掌柜記賬的例子說明 redo log的作用。

酒店掌柜有一個粉板，專門用來記錄客人的賒賬記錄。如果賒賬的人不多，那麼他可以把顧客名和賬目寫在板上。但如果賒賬的人多了，粉板總會有記不下的時候，這個時候掌柜一定還有一個專門記錄賒賬的賬本

如果有人要賒賬或者還賬的話，掌柜一般有兩種做法：

直接翻開賬本記錄（直接寫磁碟）
先記在粉板（redo log）上，等空閑時再記錄到賬本（磁碟）上

當生意火爆時，不停有人來要賒賬或者還賬（更新操作），如果掌柜還是用第一種做法，由於記到賬本上需要查找記錄（隨機讀）那就會出現大量的人（更新操作）在等待，會影響工作（阻塞）。

第二種做法，先記在粉板上，空閑時再寫回賬本。因為記粉板的速度是很快的，就能大量處理賒賬或者還賬，當掌柜（MySQL）沒那麼忙的時候，就把粉板上的內容記到賬本上。但如果粉板（redo log）寫滿了，那這時候掌柜（MySQL）就要停下工作，先去把粉板（redo log）的內容寫回賬本（磁碟）。

兩種做法的區別是：

第一種是要找到記錄後更新，這裡涉及隨時讀，而隨時讀是很費時間的
第二種是記在日誌上，這是順序寫的，而順序寫是很快的

因此MySQL採用第二種做法，當有一條記錄需要更新的時候，InnoDB引擎就會先把記錄寫到redo log（粉板）裡面，並更新記憶體，這個時候更新就算完成了。同時，InnoDB引擎會在適當的時候，將這個操作記錄更新到磁碟裡面，而這個更新往往是在系統比較空閑的時候做，這就像打烊以後掌柜做的事。

這就是WAL（Write-Ahead Logging），先寫日誌，再寫磁碟。

與粉板類似，redo log 也是有固定大小的。比如可以配置為一組4個文件，每個文件的大小是1GB，那麼這塊「粉板」總共就可以記錄4GB的操作。從頭開始寫，寫到末尾就又回到開頭循環寫，如下面這個圖所示。

兩個指針：

write pos是當前記錄的位置
checkpoint是當前要擦除的位置

有了 redo log，InnoDB 可以保證即使資料庫發生異常重啟，之前提交的記錄都不會丟失，這個能力稱為 crash-safe。

如何寫入

下面以一條Update語句來介紹 binlog 是如何記錄的。這裡在 binlog 里也有介紹過。

mysql> update T set c=c+1 where ID=2;

取得 ID=2 這一行（通過記憶體或磁碟讀取）
這行的 c 值加1
更新到記憶體
寫入 redo log（處於 prepare 階段）
寫 binlog
提交事務（處於 commit 狀態）

兩階段提交

上面的流程採用了兩階段提交，那為什麼要採用兩階段提交呢？是為了讓 binlog 和 redo log 之間的邏輯一致。

我們假設一下上面的 update 語句在執行的每個時刻，MySQL 崩潰了，看一下兩個日誌間的邏輯是如何保持一致的。

假設在步驟4前，MySQL崩潰重啟，那麼事務提交失敗，不會影響數據。雖然更新了記憶體，但崩潰後，記憶體會丟失。
假設在步驟4完成後崩潰，此時已經寫入 redo log 了，重啟後，發現 redo log 處於 prepare 階段，就不恢復。
假設在步驟5完成後崩潰，此時已經寫入 binlog 了，重啟後，發現 binlog 已經寫入了，就把對應的 redo log 改為 commit 狀態。

這樣就能保證 redo log 和 binlog 的邏輯一致性。

兩階段提交是跨系統維持數據邏輯一致性時常用的一個方案。

如何使用

這裡要介紹一下 redo log 里非常重要的一個參數：innodb_flush_log_at_trx_commit。

innodb_flush_log_at_trx_commit=0 表示提交事務的時候，不立即把 redo log buffer 里的數據刷入磁碟文件的，而是依靠 InnoDB 的主執行緒每秒執行一次刷新到磁碟。此時可能你提交事務了，結果 mysql 宕機了，然後此時記憶體里的數據全部丟失。

innodb_flush_log_at_trx_commit=1 表示提交事務的時候，就必須把 redo log 從記憶體刷入到磁碟文件里去，只要事務提交成功，那麼 redo log 就必然在磁碟里了。注意，因為作業系統的「延遲寫」特性，此時的刷入只是寫到了作業系統的緩衝區中，因此執行同步操作才能保證一定持久化到了硬碟中。

innodb_flush_log_at_trx_commit=2 表示提交事務的時候，把 redo 日誌寫入磁碟文件對應的 os cache 快取里去，而不是直接進入磁碟文件，可能 1 秒後才會把 os cache 里的數據寫入到磁碟文件里去。

如何選擇

對數據丟失很敏感，設置為1，保證寫到磁碟上。但性能較差。
對數據不太敏感，設置為0或2，性能較好。但可能會丟失1秒的數據。

如何查看和設置

通過以下命令查看當前 innodb_flush_log_at_trx_commit 的值是多少：

mysql> select @@innodb_flush_log_at_trx_commit;
+----------------------------------+
| @@innodb_flush_log_at_trx_commit |
+----------------------------------+
|                                1 |
+----------------------------------+
1 row in set (0.00 sec)

在 /etc/mysql/my.cnf 文件里設置 innodb_flush_log_at_trx_commit 選項：

#/etc/mysql/my.cnf
innodb_flush_log_at_trx_commit=1

修改後，重啟 MySQL 服務即可。

redo log 與 binlog 的區別

redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實現的，所有引擎都可以使用。
redo log 是物理日誌，記錄的是「在某個數據頁上做了什麼修改」；binlog 是邏輯日誌，記錄的是這個語句的原始邏輯
redo log 是循環寫的，空間固定會用完；binlog 是可以追加寫入的。

參考資料

Tags: MySQL