MySQL中有2大非常重要的日誌，redo log和binlog。
一、redo log和binlog是什麼
- redo log 是innodb引擎特有的日誌，記錄的是對物理頁的修改，屬於物理日誌。
- binlog是sever層生成的日誌，獨立於各個引擎存在，屬於邏輯日誌。
二、redo log存在的必要性
- WAL技術：Write-Ahead Logging，先寫日誌，再寫磁盤。
- redo log可以保證數據庫有crash safe的能力，因爲只要redo log保存下來了，這時數據庫崩潰了，那些更改的數據在內存中還沒寫入磁盤，當數據庫重啓的時候，可以通過redo log將數據庫恢復至崩潰前的時間點。
- redo log是順序寫，而且可以組提交，所以寫入速度相比寫數據要快很多。而redo log寫完之後就可以提交事務，髒數據可以在後面慢慢寫盤。redo log還有buffer，加快寫入速度，innodb_log_buffer_size參數就是buffer的大小。
- redo log是循環寫，不歸檔，所以redo log不能用來恢復數據庫，只用作崩潰恢復。這和oracle使用redo log完成崩潰恢復、恢復數據庫、主備同步等是不一樣的。因爲mysql的存儲引擎是插件式的，同一個數據庫中可以有不同存儲引擎的表，而redo log是innodb存儲引擎特有的，所以恢復mysql數據庫，需要一個獨立於各個引擎的日誌，那就是bin log。
二、binlog存在的必要性
- binlog是server層實現的，獨立於各個存儲引擎，是用來恢復數據庫的唯一手段。
- binlog能保證crash safe嗎，如果能，就不需要redo log了。
三、二階段提交2pc
- redo log保證崩潰恢復，binlog用來恢復數據庫，那他們二者如何保持一致呢。例如數據庫崩潰時，redo log記錄了，但是binlog沒有記錄，那麼恢復後，數據存在，但是其他場景使用binlog恢復時，就會不一致。
- 具體是 1、redo log prepare 2、寫binlog 3、commit，當在第一步完成後數據庫崩潰，因爲binlog沒有記錄，直接回滾；如果第二步完成後數據庫崩潰，雖然沒有commit，但是兩個日誌都有記錄，所以事務可以認爲是完整的。所以崩潰恢復時判斷一個事物是提交還是回滾，主要看事務id是不是存在於binlog中。