前面介紹了三種日誌：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 是可以追加寫入的。