| 1. binlog是MySQL Server層記錄的日誌， redo log是InnoDB存儲引擎層的日誌。 兩者都是記錄了某些操作的日誌(不是所有)自然有些重複（但兩者記錄的格式不同）。 2. 選擇binlog日誌作爲replication我想主要原因是MySQL的特點就是支持多存儲引擎，爲了兼容絕大部分引擎來支持複製這個特性，那麼自然要採用MySQL Server自己記錄的日誌而不是僅僅針對InnoDB的redo log，因爲如果採用了InnoDB redo log複製，那麼其他引擎也想複製，此時改怎麼辦呢？對吧 |
binlog屬於邏輯日誌，是邏輯操作。innodb redo屬於物理日誌，是物理變更。
邏輯日誌有個缺點是難以並行，而物理日誌可以比較好的並行操作，所以redo複製還是有優勢的，也許5.7能搞出來。
什麼是binlog
binlog日誌用於記錄所有更新且提交了數據或者已經潛在更新提交了數據（例如，沒有匹配任何行的一個DELETE）的所有語句。語句以“事件”的形式保存，它描述數據更改。
binlog作用
1.恢復使能夠最大可能地更新數據庫，因爲二進制日誌包含備份後進行的所有更新。
2.在主複製服務器上記錄所有將發送給從服務器的語句。
binlog 主要參數
log_bin
設置此參數表示啓用binlog功能，並指定路徑名稱
innodb_flush_log_at_trx_commit = N：
N=0 – 每隔一秒，把事務日誌緩存區的數據寫到日誌文件中，以及把日誌文件的數據刷新到磁盤上；
N=1 – 每個事務提交時候，把事務日誌從緩存區寫到日誌文件中，並且刷新日誌文件的數據到磁盤上；
N=2 – 每事務提交的時候，把事務日誌數據從緩存區寫到日誌文件中；每隔一秒，刷新一次日誌文件，但不一定刷新到磁盤上，而是取決於操作系統的調度；
sync_binlog = N：
N>0 — 每向二進制日誌文件寫入N條SQL或N個事務後，則把二進制日誌文件的數據刷新到磁盤上；
N=0 — 不主動刷新二進制日誌文件的數據到磁盤上，而是由操作系統決定；
推薦配置組合：
N=1,1 — 適合數據安全性要求非常高，而且磁盤IO寫能力足夠支持業務，比如充值消費系統；
N=1,0 — 適合數據安全性要求高，磁盤IO寫能力支持業務不富餘，允許備庫落後或無複製；
N=2,0或2,m(0<m<100) — 適合數據安全性有要求，允許丟失一點事務日誌，複製架構的延遲也能接受；
N=0,0 — 磁盤IO寫能力有限，無複製或允許複製延遲稍微長點能接受，例如：日誌性登記業務；
Undo Log
Undo Log是爲了實現事務的原子性，在MySQL數據庫InnoDB存儲引擎中，還用UndoLog來實現多版本併發控制(簡稱：MVCC)。
-事務的原子性(Atomicity)
事務中的所有操作，要麼全部完成，要麼不做任何操作，不能只做部分操作。如果在執行的過程中發了錯誤，要回滾(Rollback)到事務開始前的狀態，就像這個事務從來沒有執行過。
-原理
Undo Log的原理很簡單，爲了滿足事務的原子性，在操作任何數據之前，首先將數據備份到一個地方（這個存儲數據備份的地方稱爲UndoLo）。
然後進行數據的修改。如果出現了錯誤或者用戶執行了ROLLBACK語句，系統可以利用UndoLog中的備份將數據恢復到事務開始之前的狀態。
除了可以保證事務的原子性，Undo Log也可以用來輔助完成事務的持久化。
-事務的持久性(Durability)
事務一旦完成，該事務對數據庫所做的所有修改都會持久的保存到數據庫中。爲了保證持久性，數據庫系統會將修改後的數據完全的記錄到持久的存儲上。
-用Undo Log
實現原子性和持久化的事務的簡化過程
假設有A、B兩個數據，值分別爲1,2。
A.事務開始.
B.記錄A=1到undolog.
C.修改A=3.
D.記錄B=2到undolog.
E.修改B=4.
F.將undolog寫到磁盤。
G.將數據寫到磁盤。
H.事務提交
這裏有一個隱含的前提條件：‘數據都是先讀到內存中，然後修改內存中的數據，最後將數據寫回磁盤’。
之所以能同時保證原子性和持久化，是因爲以下特點：
A.更新數據前記錄Undo log。
B.爲了保證持久性，必須將數據在事務提交前寫到磁盤。只要事務成功提交，數據必然已經持久化。
C.Undo log
必須先於數據持久化到磁盤。如果在G,H之間系統崩潰，undo log是完整的，可以用來回滾事務。
D.如果在A-F之間系統崩潰,因爲數據沒有持久化到磁盤。所以磁盤上的數據還是保持在事務開始前的狀態。
缺陷：每個事務提交前將數據和Undo Log寫入磁盤，這樣會導致大量的磁盤IO，因此性能很低。
如果能夠將數據緩存一段時間，就能減少IO提高性能。但是這樣就會喪失事務的持久性。因此引入了另外一種機制來實現持久化，即
Redo log
記錄的是新數據的備份。在事務提交前，只要將Redo Log持久化即可，不需要將數據持久化。當系統崩潰時，雖然數據沒有持久化，
但是RedoLog已經持久化。系統可以根據RedoLog的內容，將所有數據恢復到最新的狀態。
-Undo+Redo
事務的簡化過程
假設有A、B兩個數據，值分別爲1,2.
A.事務開始.
B.記錄A=1到undolog.
C.修改A=3.
D.記錄A=3到redolog.
E.記錄B=2到undolog.
F.修改B=4.
G.記錄B=4到redolog.
H.將redolog寫入磁盤。
I.事務提交
-Undo+Redo
事務的特點
A.爲了保證持久性，必須在事務提交前將
RedoLog持久化。
B.數據不需要在事務提交前寫入磁盤，而是緩存在內存中。
C.RedoLog保證事務的持久性。
D.UndoLog保證事務的原子性。
E.有一個隱含的特點，數據必須要晚於redolog寫入持久存