mysql探究-redolog和binlog的設計思路

mysql的更新流程，會牽涉到它的日志子產品：redolog和binlog

redolog（重做日志）

redolog是Mysq的InnoDB引擎中才有的日志子產品。

如果每次更改操作，都要進行一次日志磁盤寫入，行資料磁盤更改，整個過程的IO就會很高，那InnoDB是怎麼處理的呢？

當更新一條資料時，InnoDB會找到要更新的行資料，把做了什麼修改記錄寫到redolog中，并把這行資料更新到記憶體中，整個過程就算完成了。

redolog是固定大小的（如下圖），是以它隻能循環記錄做了什麼修改，write pos為目前記錄的位置，check point為目前可以擦除的位置，代表更新的行已經完成資料庫的磁盤更改。如果前者速度，隻能等待。

如果此時當機了， 記憶體中更改後的行資料已經不再了， 但是redolog還是存在的，是可以恢複，這也就是mysql的crash-safe特性。

binlog（歸檔日志）

binlog存在Mysql的Server中，和引擎無關。

binlog記錄的不是做了什麼修改，而是真正記錄了邏輯，比如 SET age = 2 WHERE ID =1。

binlog存儲是追加型的，不會覆寫。

兩個日志是如何互動在一起的？

以SET age = 2 WHERE ID =1為例， 順序如下：

1. Server層調用引擎層先找到ID =1的資料（如果記憶體裡有，直接記憶體傳回）
2. 引擎層在記憶體中進行age改為2，同時将記錄寫到redolog，日志處于prepare狀态
3. 整個更改完成，Server層寫入一條binlog
4. Server層再調用引擎層送出事務，引擎層把剛剛寫入的redolog改為commit狀态。
5. 引擎層當空閑或timeout時，會對commit狀态的redolog進行處理，将更新持久化到磁盤。

可以看到其中有兩階段的送出，好處在于上述任一環節中突然當機，也能不受影響。

總結

binlog和redolog，兩個分工明确，可以讓我們提高更新效率，又能保證正常資料不丢失。分析redolog能知道目前引擎處理的飽和程度，通過binlog還能做更多業務處理。

我們的各種系統設計時，如果也很關注一緻性，也可以借鑒此類方式。