MySQL日誌系統bin log、redo log和undo log

　　  今人不見古時月，今月曾經照古人。

簡介：日誌是MySQL資料庫的重要組成部分，記錄著資料庫執行期間各種狀態資訊，主要包括錯誤日誌、查詢日誌、慢查詢日誌、事務日誌、二進位制日誌幾大類。在此重點關注二進位制日誌bin log和事務日誌(包括redo log 和 undo log )。

一、概念

redo log、undo log&bin log

重做日誌（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），但資料還沒真正寫到磁碟的時候。此時我們的資料庫掛了，我們可以對資料進行恢復。

二、bin log

binlog 用於記錄資料庫執行的寫入性操作(不包括查詢)資訊，以二進位制的形式儲存在磁碟中。binlog 是 mysql的邏輯日誌，並且由 Server 層進行記錄，使用任何儲存引擎的 mysql 資料庫都會記錄 binlog 日誌。可以簡單的理解為它儲存著每條變更的SQL語句。

  • 可以通過binlog來對資料進行恢復；
  • binlog 可以用於主從複製中，從庫利用主庫上的 binlog 進行重播，實現主從同步。用於資料庫的基於時間點、位點等的還原操作。binlog 的模式分三種：Statement、Row、Mixed；
  • binlog 是通過追加的方式進行寫入的，可以通過max_binlog_size 引數設定每個 binlog檔案的大小，當檔案大小達到給定值之後，會生成新的檔案來儲存日誌；
  • 邏輯日誌：可以簡單理解為記錄的就是sql語句；
  • 物理日誌：mysql 資料最終是儲存在資料頁中的，物理日誌記錄的就是資料頁變更。

binlog使用場景

在實際應用中， binlog 的主要使用場景有兩個，分別是 主從複製 和 資料恢復。

  1. 主從複製 ：在 Master 端開啟 binlog ，然後將 binlog傳送到各個 Slave 端， Slave 端重放 binlog 從而達到主從資料一致。
  2. 資料恢復 ：通過使用 mysqlbinlog 工具來恢復資料。

binlog刷盤時機

對於 InnoDB 儲存引擎而言，只有在事務提交時才會記錄biglog ，此時記錄還在記憶體中，那麼 biglog是什麼時候刷到磁碟中的呢？mysql 通過 sync_binlog 引數控制 biglog 的刷盤時機，取值範圍是 0-N：

  • 0：不去強制要求，由系統自行判斷何時寫入磁碟；
  • 1：每次 commit 的時候都要將 binlog 寫入磁碟；
  • N：每N個事務，才會將 binlog 寫入磁碟。

從上面可以看出， sync_binlog 最安全的是設定是 1 ，這也是MySQL 5.7.7之後版本的預設值。但是設定一個大一些的值可以提升資料庫效能，因此實際情況下也可以將值適當調大，犧牲一定的一致性來獲取更好的效能。

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 模式

基於STATMENT 和 ROW 兩種模式的混合複製(mixed-based replication, MBR )，一般的複製使用STATEMENT 模式儲存 binlog ，對於 STATEMENT 模式無法複製的操作使用 ROW 模式儲存 binlog。比如遇到表結構變更的時候就會以 statement 模式來記錄，如果 SQL 語句確實就是 update 或者 delete 等修改資料的語句，那麼還是會記錄所有行的變更即採用ROW模式。

bin log生命週期

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

三、redo log

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

為什麼需要redo log？

我們都知道，事務的四大特性裡面有一個是 永續性，具體來說就是隻要事務提交成功，那麼對資料庫做的修改就被永久儲存下來了，不可能因為任何原因再回到原來的狀態。

那麼 mysql是如何保證一致性的呢？最簡單的做法是在每次事務提交的時候，將該事務涉及修改的資料頁全部重新整理到磁碟中。但是這麼做會有嚴重的效能問題，主要體現在兩個方面：

  • 因為 Innodb 是以 頁 為單位進行磁碟互動的，而一個事務很可能只修改一個數據頁裡面的幾個位元組，這個時候將完整的資料頁刷到磁碟的話，太浪費資源了！
  • 一個事務可能涉及修改多個數據頁，並且這些資料頁在物理上並不連續，使用隨機IO寫入效能太差！

因此 mysql 設計了 redo log，具體來說就是隻記錄事務對資料頁做了哪些修改，這樣就能完美地解決效能問題了(相對而言檔案更小並且是順序IO)。

redo log基本概念

redo log 包括兩部分：一個是記憶體中的日誌緩衝( redo log buffer )，另一個是磁碟上的日誌檔案( redo logfile)。mysql 每執行一條 DML 語句，先將記錄寫入 redo log buffer，後續某個時間點再一次性將多個操作記錄寫到 redo log file。這種 先寫日誌，再寫磁碟 的技術就是 MySQL裡經常說到的 WAL(Write-Ahead Logging) 技術。在計算機作業系統中，使用者空間( user space )下的緩衝區資料一般情況下是無法直接寫入磁碟的，中間必須經過作業系統核心空間( kernel space )緩衝區( OS Buffer )。因此， redo log buffer 寫入 redo logfile 實際上是先寫入 OS Buffer ，然後再通過系統呼叫 fsync() 將其刷到 redo log file中。

mysql 支援三種將 redo log buffer 寫入 redo log file 的時機，可以通過 innodb_flush_log_at_trx_commit 引數配置，各引數值含義如下：

  • 0：延遲寫。不會在事務提交時立即將redo log buffer寫入到os buffer，而是每秒寫入os buffer，然後立即寫入到redo log file，也就是每秒刷盤；
  • 1：實時寫，實時刷。每次事務提交都會將redo log buffer寫入os buffer，然後立即寫入redo log file。資料能夠及時入盤，但是每次事務提交都會刷盤，效率較低；
  • 2：實時寫，延時刷。每次事務提交都將redo log buffer寫入os buffer，然後每秒將os buffer寫入redo log file。

redo log記錄形式

前面說過， redo log 實際上記錄資料頁的變更，而這種變更記錄是沒必要全部儲存，因此 redo log實現上採用了大小固定，迴圈寫入的方式，當寫到結尾時，會回到開頭迴圈寫日誌

在innodb中，既有redo log 需要刷盤，還有 資料頁 也需要刷盤， redo log存在的意義主要就是降低對 資料頁 刷盤的要求 ** 。在上圖中， write pos 表示 redo log 當前記錄的 LSN (邏輯序列號)位置， check point 表示 資料頁更改記錄 刷盤後對應 redo log 所處的 LSN(邏輯序列號)位置。write pos 到 check point 之間的部分是 redo log 空著的部分，用於記錄新的記錄；check point 到 write pos 之間是 redo log 待落盤的資料頁更改記錄。當 write pos追上check point 時，會先推動 check point 向前移動，空出位置再記錄新的日誌。啟動 innodb 的時候，不管上次是正常關閉還是異常關閉，總是會進行恢復操作。因為 redo log記錄的是資料頁的物理變化，因此恢復的時候速度比邏輯日誌(如 binlog )要快很多。重啟innodb 時，首先會檢查磁碟中資料頁的 LSN ，如果資料頁的LSN 小於日誌中的 LSN ，則會從 checkpoint 開始恢復。還有一種情況，在宕機前正處於checkpoint 的刷盤過程，且資料頁的刷盤進度超過了日誌頁的刷盤進度，此時會出現資料頁中記錄的 LSN 大於日誌中的 LSN，這時超出日誌進度的部分將不會重做，因為這本身就表示已經做過的事情，無需再重做。

redo log與binlog區別

由 binlog 和 redo log 的區別可知：binlog 日誌只用于歸檔，只依靠 binlog 是沒有 crash-safe 能力的。但只有 redo log 也不行，因為 redo log 是 InnoDB特有的，且日誌上的記錄落盤後會被覆蓋掉。因此需要 binlog和 redo log二者同時記錄，才能保證當資料庫發生宕機重啟時，資料不會丟失。

四、undo log

資料庫事務四大特性中有一個是 原子性 ，具體來說就是 原子性是指對資料庫的一系列操作，要麼全部成功，要麼全部失敗，不可能出現部分成功的情況。實際上， 原子性 底層就是通過 undo log 實現的。undo log主要記錄了資料的邏輯變化，比如一條 INSERT 語句，對應一條DELETE 的 undo log ，對於每個 UPDATE 語句，對應一條相反的 UPDATE 的 undo log ，這樣在發生錯誤時，就能回滾到事務之前的資料狀態。同時， undo log 也是 MVCC(多版本併發控制)實現的關鍵。

主要作用

  1. 儲存了事務發生之前的資料的一個版本，可以用於回滾；
  2. 同時可以提供多版本併發控制下的讀（MVCC），也即非鎖定讀。

生命週期

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

儲存內容

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

儲存位置

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

五、兩階段提交

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

MySQL最開始是沒有InnoDB引擎的，binlog日誌位於Server層，只是用於歸檔和主從複製，本身不具備crash safe的能力。而InnoDB依靠redo log具備了crash safe的能力，redo log和bin log同時記錄，就需要保證兩者的一致性。兩個log的寫入流程是：

寫入redo log->事務狀態設定為prepare->寫入bin log->提交事務->修改redo log事務狀態為commit

將 redo log 的寫入拆成了兩個步驟：prepare 和 commit，先prepare後commit，這個稱為兩段提交。

那麼為什麼需要兩個段提交呢？redo log和binlog是兩種不同的日誌，就類似於分散式中的多節點提交請求，需要保證事務的一致性。redo log和binlog有一個公共欄位XID，代表事務ID。當引數innodb_support_xa開啟時，在執行事務的第一條SQL時候會去註冊XA，根據第一條SQL的query id拼湊XID資料，然後儲存在事務物件中。
如果兩個日誌單純的分開提交，則可能會引發一些問題，如果簡單分開提交，那麼對於一條更新語句執行，有兩種情況：

  • 先寫binlog，後寫redo log：如果binlog寫入了，在寫redo log之前資料庫宕機。那麼在重啟恢復的時候，通過binlog恢復了資料沒問題。但是由於redo log沒有寫入，這個事務應該無效，也就是原庫中就不應該有這條語句對應的更新。但是通過binlog恢復資料後，資料庫中就多了這條更新
  • 先寫redo log，後寫binlog：如果redo log寫入了，在寫binlog之前資料庫宕機。那麼在重啟恢復的時候，通過binlog恢復從庫，那麼相對於主庫來說，從庫就少了這條更新

採取了兩段提交之後，怎麼做crash恢復呢？如果在寫入binlog之前宕機了，那麼事務需要回滾；如果事務commit之前宕機了，那麼此時binlog cache中的資料可能還沒有刷盤，那麼驗證binlog的完整性：到redo log中找到最近事務的XID，根據這個XID到binlog中去找（XID Event），如果找到了，說明在binlog中對應事務已經提交，那麼提交redo log中事務即可；否則需要回滾事務。
栗子

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

下圖是這個 update 語句的執行流程圖，圖中綠色框表示是在 InnoDB 內部執行的，灰色框表示是在執行器中執行的。

今人不見古時月

今月曾經照古人