Mysql Redo log

mysql 的日誌型別：

1. Mysql 的Redo log 是什麼

redo log 適用於崩潰恢復(crash-safe)

為什麼需要 Redo log？

事務的四大特性裡面有一個是 永續性 ，具體來說就是只要事務提交成功，那麼對資料庫做的修改就被永久儲存下來了，不可能因為任何原因再回到原來的狀態 。那麼 mysql是如何保證一致性的呢？最簡單的做法是在每次事務提交的時候，將該事務涉及修改的資料頁全部重新整理到磁碟中。但是這麼做會有嚴重的效能問題，主要體現在兩個方面：

（1）因為 Innodb 是以 頁 為單位進行磁碟互動的，而一個事務很可能只修改一個數據頁裡面的幾個位元組，這個時候將完整的資料頁刷到磁碟的話，太浪費資源了！

（2）一個事務可能涉及修改多個數據頁，並且這些資料頁在物理上並不連續，使用隨機IO寫入效能太差！

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

redo log 包括兩部分：

• 一個是記憶體中的日誌緩衝( redo log buffer )

• 另一個是磁碟上的日誌檔案( redo logfile)。 mysql 每執行一條 DML 語句，先將記錄寫入 redo log buffer
  ，後續某個時間點再一次性將多個操作記錄寫到 redo log file 。

這種 先寫日誌，再寫磁碟

2. Redo log工作原理

在計算機作業系統中，使用者空間( user space )下的緩衝區資料一般情況下是無法直接寫入磁碟的，中間必須經過作業系統核心空間( kernel space)緩衝區( OS Buffer )。因此， redo log buffer 寫入 redo log file 實際上是先寫入 OS Buffer ，然後再通過系統呼叫 fsync() 將其刷到 redo log file 中，過程如下：

innodb_flush_log_at_trx_commit

MySQL支援使用者自定義在commit時如何將log buffer中的日誌刷log file中。這種控制通過變數 innodb_flush_log_at_trx_commit

• 當設定為1的時候：事務每次提交都會將log buffer中的日誌寫入os buffer並呼叫fsync()刷到log file on disk中。這種方式即使系統崩潰也不會丟失任何資料，但是因為每次提交都寫入磁碟，IO的效能較差。
• 當設定為0的時候：事務提交時不會將log buffer中日誌寫入到os buffer，而是每秒寫入os buffer並呼叫fsync()寫入到log file on disk中。也就是說設定為0時是(大約)每秒重新整理寫入到磁碟中的，當系統崩潰，會丟失1秒鐘的資料。
• 當設定為2的時候：每次提交都僅寫入到os buffer，然後是每秒呼叫fsync()將os buffer中的日誌寫入到log file on disk。

在主從複製結構中，要保證事務的永續性和一致性，需要對日誌相關變數設定為如下：

• 如果啟用了二進位制日誌，則設定sync_binlog=1，即每提交一次事務同步寫到磁碟中。
• 總是設定innodb_flush_log_at_trx_commit=1，即每提交一次事務都寫到磁碟中。

3. Redo log的結構

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

在innodb中，既有redo log需要刷盤，還有 資料頁 也需要刷盤， redo log 存在的意義主要就是降低對 資料頁 刷盤的要求 。

（1） **write pos 表示 redo log 當前記錄的 LSN (邏輯序列號)位置， **

（2）check point 表示 資料頁更改記錄** 刷盤後對應 redo log 所處的 LSN (邏輯序列號)位置。

（3）write pos 到 check point 之間的部分是 redo log 空著的部分，用於記錄新的記錄；

（4）check point到 write pos 之間是 redo log 待落盤的資料頁更改記錄。當 write pos 追上 check point 時，會先推動 check point 向前移動，空出位置再記錄新的日誌。

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

redo log日誌的大小是固定的，即記錄滿了以後就從頭迴圈寫。

圖片來自極客時間，該圖展示了一組4個檔案的redo log日誌，checkpoint之前表示擦除完了的，即可以進行寫的，擦除之前會更新到磁碟中，write pos是指寫的位置，當write pos和checkpoint相遇的時候表明redo log已經滿了，這個時候資料庫停止進行資料庫更新語句的執行，轉而進行redo log日誌同步到磁碟中。

Innodb 啟動與重啟

• 啟動 innodb 的時候，不管上次是正常關閉還是異常關閉，總是會進行恢復操作。因為 redo log 記錄的是資料頁的物理變化，因此恢復的時候速度比邏輯日誌(如 binlog )要快很多。
• 重啟 innodb 時，首先會檢查磁碟中資料頁的 LSN ，如果資料頁的 LSN 小於日誌中的 LSN ，則會從 checkpoint 開始恢復。 還有一種情況，在宕機前正處於checkpoint 的刷盤過程，且資料頁的刷盤進度超過了日誌頁的刷盤進度，此時會出現資料頁中記錄的 LSN 大於日誌中的 LSN，這時超出日誌進度的部分將不會重做，因為這本身就表示已經做過的事情，無需再重做。

LSN (Log Sequence Number)

LSN實際上就是InnoDB使用的一個版本標記的計數，它是一個單調遞增的值。資料頁和redo log都有各自的LSN。我們可以根據資料頁中的LSN值和redo log中LSN的值判斷需要恢復的redo log的位置和大小。

redo log與binlog區別

參考：

https://zhuanlan.zhihu.com/p/35355751

https://dev.mysql.com/doc/refman/5.7/en/innodb-redo-log.html

http://mysql.taobao.org/monthly/2015/05/01/

https://segmentfault.com/a/1190000023827696

https://blog.csdn.net/u010002184/article/details/88526708