RedoLog和Binlog區別
1. redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 層實現的，所有引擎
都可以使用。
2. redo log 是邏輯物理日誌，頁面內的操作記錄的是邏輯日誌，頁間的操作記錄的是物理日誌；binlog 是邏輯日
志，相當於是Mysql server層的日誌，適用於所有引擎，且可以通過參數控制寫入。
3. redo log 是循環寫的，空間固定會用完；binlog 是可以追加寫入的。“追加寫”是指
binlog 文件寫到一定大小後會切換到下一個，並不會覆蓋以前的日誌。
備註：
數據庫的日誌類型大概可以分爲以下三種：
邏輯日誌：記錄的是sql語句的原始邏輯，面向對象是邏輯結構如表、列等
物理日誌：記錄的是文件記錄的改變，面向對象是表空間、數據文件、數據頁、偏移量等
邏輯物理日誌：頁面內的操作記錄的是邏輯日誌，頁間的操作記錄的是物理日誌，physical to a page，logical within a page
一條更新語句的執行流程爲：
數據頁到內存中——>修改數據——>更新數據頁——>寫入redolog（狀態爲prepare）——>寫binlog-->提交事務（redolog狀態修改爲commit）；
使用兩階段提交的優勢就是如果數據庫發生了意外情況，宕機、斷點、重啓等等，可以保證使用BinLog恢復數據和當時數據狀態一致；
具體情況下的策略如下：
binlog有記錄，redolog狀態commit：正常完成的事務，不需要恢復
binlog有記錄，redolog狀態prepare：在binlog寫完提交事務之前的crash，恢復操作：提交事務
binlog無記錄，redolog狀態prepare：在binlog寫完之前的crash，恢復操作：回滾事務
binlog無記錄，redolog無記錄：在redolog寫之前crash，恢復操作：回滾事務
小結：
redo log 用於保證 crash-safe 能力。innodb_flush_log_at_trx_commit 這個參數設置成1 的時候，表示每次事務的 redo log 都直接持久化到磁盤。這個參數我建議你設置成 1，這樣可以保證 MySQL 異常重啓之後數據不丟失。
sync_binlog 這個參數設置成 1 的時候，表示每次事務的 binlog 都持久化到磁盤。這個參數我也建議你設置成 1，這樣可以保證 MySQL 異常重啓之後 binlog 不丟失。