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寫入持久存