redo log與binlog與undo log

綜述

binlog二進制日誌是mysql-server層的，主要是作主從複製，時間點恢復使用
redo log重作日誌是InnoDB存儲引擎層的，用來保證事務安全
undo log回滾日誌保存了事務發生以前的數據的一個版本，能夠用於回滾，同時能夠提供多版本併發控制下的讀（MVCC），也即非鎖定讀

主備數據一致性

爲了保證master和slave的數據一致性，則binlog和redo log保持一致
不然當binlog寫完未fsync，主庫crash了，備庫卻執行了，數據會不一致
binlog是mysql內部實現二階段提交的協調者
爲每一個事務分配一個XID
一階段：
事務狀態爲prepare，redo log和undo log已經記錄了對應的日誌
二階段：

1. binlog 完成write和fsync後，成功，事務必定提交了，不然回滾
2. 發送commit，清除undo信息，刷redo，設置事務狀態爲completed

故障恢復是如何作的

當出現crash等問題，經過掃描binlog中全部的xid，告知innodb，innodb回滾其它事務

須要保證binlog寫入和redo log事務提交順序一致性

若是不一致，會致使數據不一致
BLGC(Binary Log Group Commit) 解決串行prepare_commit_mutex的問題
引入隊列解決，

區別

redo log在事務沒有提交前，每個修改操做都會記錄變動後的數據，保存的是物理日誌->數據
防止在發生故障的時間點，尚有髒頁未寫入磁盤，在重啓mysql服務的時候，根據redo log進行重作，從而達到事務的持久性這一特性.
redo log只是先寫入Innodb_log_buffer，定時fsync到磁盤

binlog只會在日誌提交後，一次性記錄執行過的事務中的sql語句以及其反向sql(做爲回滾用)，保存的是邏輯日誌->執行的sql語句
undo log事務開始以前，將當前版本生成undo log，undo 也會產生 redo 來保證undo log的可靠性，保存的是邏輯日誌->數據前一個版本

• 基於redo log直接恢復數據的效率 高於 基於binglog sql語句恢復
• binlog不是循環使用，在寫滿或者重啓以後，會生成新的binlog文件，redo log是循環使用。
• binlog能夠做爲恢復數據使用，主從複製搭建，redo log做爲異常宕機或者介質故障後的數據恢復使用。

做者：嘵曉的故事
連接：https://www.jianshu.com/p/090087c22820
來源：簡書
簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。