總結下重做日誌（redo log）、回滾日誌（undo log）、二進位制日誌（binlog）的概念。

• redo log 是物理日誌，undo log 和 binlog 是邏輯日誌
• binlog二進位制日誌是server層的無論MySQL用什麼引擎，都會有的，主要是左主從複製，時間點恢復使用
• redo log重做日誌是InnoDB儲存引擎層的，用來保證事務安全
• undo log回滾日誌儲存了事務發生之前的資料的一個版本，可以用於回滾，同時可以提供多版本併發控制下的讀（MVCC），也即非鎖定讀

crash-safe概念

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

舉個列子：當我們修改的時候，寫完記憶體了（buffer），但資料還沒真正寫到磁碟的時候。此時我們的資料庫掛了，我們可以對資料進行恢復

redo log (重做日誌)

redo log 是物理日誌，記載著每次在某個頁上做了什麼修改。寫redo log也是需要寫磁碟的，但它的好處就是順序IO（我們都知道順序IO比隨機IO快非常多）。寫入的速度很快

生命週期

1. 事務開始之後，就開始產生 redo log 日誌了，在事務執行的過程中，redo log 開始逐步落盤
2. 當對應事務的髒頁寫入到磁碟之後，redo log 的使命就完成了，它所佔用的空間也就可以被覆蓋了。
3. InnoDB 的 redo log 是固定大小的，比如可以配置為一組 4 個檔案，每個檔案的大小是 1GB。從頭開始寫，寫到末尾就又回到開頭迴圈寫

1. write pos 是當前記錄的位置，一邊寫一邊後移，寫到第 3 號檔案末尾後就回到 0 號檔案開頭。checkpoint 是當前要擦除的位置，也是往後推移並且迴圈的，擦除記錄前要把記錄更新到資料檔案。
2. write pos 和 checkpoint 之間的的部分，可以用來記錄新的操作。如果 write pos 追上 checkpoint，表示“粉板”滿了，這時候不能再執行新的更新，得停下來先擦掉一些記錄，把 checkpoint 推進一下。

儲存內容

redo log 包括兩部分：

• 一是記憶體中的日誌緩衝(redo log buffer)，該部分日誌是易失性的；
• 二是磁碟上的重做日誌檔案(redo log file)，該部分日誌是持久的，redo log 儲存的是物理格式的日誌，記錄的是物理資料頁面的修改資訊，它是順序寫入 redo log file 中的。

落盤方式（將 innodb 日誌緩衝區的日誌重新整理到磁碟）

1. Master Thread 每秒一次執行重新整理 Innodb_log_buffer 到重做日誌檔案
2. 每個事務提交時會將重做日誌重新整理到重做日誌檔案
3. 當重做日誌快取可用空間少於一半時，重做日誌快取被重新整理到重做日誌檔案

注意：

1. 其實寫redo log的時候，也會有buffer，是先寫buffer，再真正落到磁碟中的。至於從buffer什麼時候落磁碟，會有配置供我們配置。
2. redo log 是 InnoDB 引擎特有的日誌
3. 永續性就是靠redo log來實現的（如果寫入記憶體成功，但資料還沒真正刷到磁碟，如果此時的資料庫掛了，我們可以靠redo log來恢復記憶體的資料，這就實現了永續性）。

undo log (回滾日誌)

u儲存了事務發生之前的資料的一個版本，作用：

1. 可以用於回滾
2. 同時可以提供多版本併發控制下的讀（MVCC），也即非鎖定讀

   生命週期

3. 事務開始之前，將當前事務版本生成 undo log，undo log 也會產生 redo log 來保證 undo log 的可靠性。
4. 當事務提交之後，undo log 並不能立馬被刪除，而是放入待清理的連結串列，
5. 由 purge 執行緒判斷是否有其它事務在使用 undo 段中表的上一個事務之前的版本資訊，從而決定是否可以清理 undo log 的日誌空間。

儲存內容

undo log 儲存的是邏輯格式的日誌，儲存了事務發生之前的上一個版本的資料，可以用於回滾。當一箇舊的事務需要讀取資料時，為了能讀取到老版本的資料，需要順著 undo 鏈找到滿足其可見性的記錄。

儲存位置

預設情況下，undo 檔案是儲存在共享表空間的，也即 ibdatafile 檔案中，當資料庫中發生一些大的事務性操作的時候，要生成大量的 undo log 資訊，這些資訊全部儲存在共享表空間中，因此共享表空間可能會變得很大，預設情況下，也就是 undo log 使用共享表空間的時候，被“撐大”的共享表空間是不會、也不能自動收縮的。因此，MySQL5.7 之後的“獨立 undo 表空間”的配置就顯得很有必要了。

binlog （二進位制日誌）

• binlog我們可以簡單理解為：儲存著每條變更的SQL語句
• 可以通過binlog來對資料進行恢復
• binlog 可以用於主從複製中，從庫利用主庫上的 binlog 進行重播，實現主從同步。用於資料庫的基於時間點、位點等的還原操作。binlog 的模式分三種：Statement、Row、Mixed。

bin-log三種模式

Statement 模式

每一條修改資料的 sql 都會記錄到 master 的 binlog 中，slave 在複製的時候，sql 程序會解析成和原來在 master 端執行時的相同的 sql 再執行。

• 優點：在 statement 模式下首先就是解決了 row 模式的缺點，不需要記錄每一行資料的變化，從而減少了 binlog 的日誌量，節省了 I/O 以及儲存資源，提高效能。因為它只需要記錄在 master 上執行的語句的細節以及執行語句的上下文資訊。
• 缺點：在 statement 模式下，由於它是記錄的執行語句，所以，為了讓這些語句在 slave 端也能正確執行，那麼它還必須記錄每條語句在執行的時候的一些相關資訊，即上下文資訊，以保證所有語句在 slave 端和在 master 端執行結果相同。另外就是，由於 MySQL 現在發展比較快，很多新功能不斷的加入，使 MySQL 的複製遇到了不小的挑戰，自然複製的時候涉及到越複雜的內容，bug 也就越容易出現。在statement 中，目前已經發現不少情況會造成 MySQL 的複製出現問題，主要是在修改資料的時候使用了某些特定的函式或者功能才會出現，比如：sleep() 函式在有些版本中就不能被正確複製，在儲存過程中使用了 last_insert_id() 函式，可能會使 slave 和 master 上得到不一致的 id 等等。由於 row 模式是基於每一行來記錄變化的，所以不會出現類似的問題。

Row 模式

日誌中會記錄每一行資料被修改的形式，然後在 slave 端再對相同的資料進行修改。row 模式只記錄要修改的資料，只有 value，不會有 sql 多表關聯的情況。

• 優點：在 row 模式下，binlog 中可以不記錄執行的 sql 語句的上下文相關的資訊，僅僅只需要記錄哪一條記錄被修改了，修改成什麼樣了，所以 row 的日誌內容會非常清楚的記錄下每一行資料的修改細節，非常容易理解。而且不會出現某些特定情況下的儲存過程和 function，以及 trigger 的呼叫和觸發無法被正確複製問題。
• 缺點：在 row 模式下，當所有執行語句記錄到日誌中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日誌內容。

Mixed 模式

從官方文件中看到，之前的 MySQL 一直都只有基於 statement 的複製模式，直到 5.1.5 版本的 MySQL 才開始支援 row 複製。從 5.0 開始，MySQL 的複製已經解決了大量老版本中出現的無法正確複製的問題。但是由於儲存過程的出現，給 MySQL Replication 又帶來了更大的新挑戰。另外，看到官方文件說，從 5.1.8 版本開始，MySQL 提供了除 Statement 和 Row 之外的第三種複製模式：Mixed，實際上就是前兩種模式的結合。在 Mixed 模式下，MySQL 會根據執行的每一條具體的 SQL 語句來區分對待記錄的日誌形式，也就是在 statement 和 row 之間選擇一種。新版本中的 statment 還是和以前一樣，僅僅記錄執行的語句。而新版本的 MySQL 也對 row 模式做了優化，並不是所有的修改都會以 row 模式來記錄，比如遇到表結構變更的時候就會以 statement 模式來記錄，如果 SQL 語句確實就是 update 或者 delete 等修改資料的語句，那麼還是會記錄所有行的變更。

生命週期

事務提交的時候，一次性將事務中的 sql 語句（一個事務可能對應多個 sql 語句）按照一定的格式記錄到 binlog 中，這裡與 redo log 很明顯的差異就是 redo log 並不一定是在事務提交的時候才重新整理到磁碟，而是在事務開始之後就開始逐步寫入磁碟。binlog 的預設儲存時間是由引數 expire_logs_days 配置的，對於非活動的日誌檔案，在生成時間超過 expire_logs_days 配置的天數之後，會被自動刪除。

binlog和redo log 寫入的細節 - 兩階段提交

MySQL通過兩階段提交來保證redo log和binlog的資料是一致的

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

update 語句的執行流程圖，圖中淺色框表示是在 InnoDB 內部執行的，深色框表示是在執行器中執行的

將 redo log 的寫入拆成了兩個步驟：prepare 和 commit，這就是"兩階段提交"。

參考：http://xiaot123.com/mysqlbinlogredologundolog-lagwx