目錄
- 備庫為什么要設置為只讀模式？
- 備庫設置為只讀，如何與主庫保持同步更新？
- A到B的內部流程如何？
- binlog內容是什么？
- `row`格式對于恢復數據有何好處
- M-M結構的循環復制問題以及解決方案
備庫為什么要設置為只讀模式？
有這樣幾點考慮：
1、有時候一些運營類的查詢語句會被放到備庫上去查，設置為只讀可以防止誤操作
2、防止切換邏輯有bug，比如切換過程中出現雙寫（ 同時寫兩個庫(A、B ）），造成主備不一致
3、可以用 readonly 狀態，來判斷節點的角色
備庫設置為只讀，如何與主庫保持同步更新？
readonly的設置對于super權限用戶是無效的。用于同步的線程，就擁有super權限。
A到B的內部流程如何？
主庫接收到客戶端的更新請求后，執行內部事務的更新邏輯，同時寫binlog；
備庫B與主庫A之間維持一個長連接。主庫內部有一個線程，專門用于服務備庫B這個長連接。
一個事務日志同步的完整過程：
1、備庫B通過change master命令，設置主庫A的IP、端口、用戶名、密碼，以及請求binlog的起始位置（文件名+日志偏移量）
2、備庫B執行start slave命令，備庫啟動兩個線程io_thread、sql_thread。io_thread負責與主庫建立連接
3、主庫A校驗完用戶名、密碼后，按照備庫B傳過來的起始位置，讀取本地的binlog然后發給備庫B
4、備庫B拿到binlog后，寫到本地文件，稱為中轉日志(relay log)
5、sql_thread讀取中轉日志relay log ，解析日志里的命令，并執行
binlog內容是什么？
在解釋內容之前，需要知道binlog的格式。
binlog有三種格式：statement 、row、mixed
statement
binlog_format=statement 時，binlog 里面記錄的就是 SQL 語句的原文
statement格式的binlog的缺陷有個缺陷：
主備使用的索引可能是不一致的，最終導致執行刪除時刪除的數據不一致。
**row **
row 格式的 binlog 里沒有了 SQL 語句的原文，而是替換成了兩個 event： Table_map和Delete_rows.
1、 Table_map ， 用于說明操作的表是test庫的表t
2、Delete_rows ， 用于定義刪除的行為
當binlog_format = row，binlog里面記錄了真實刪除行的主鍵id，這樣binlog傳到備庫去的時候，肯定不會出現主備刪除不同行的問題
mixed
mixed格式用于哪些場景呢？
statement格式可能會導致主備不一致，所以要使用row格式
row格式比較占空間，同時也更要耗費IO資源，影響執行速度
所以采用這種方案，采用mixed格式，MySQL自己會判斷這條SQL語句是否可能引起主備不一致，如果可能，使用row格式，否則使用statement格式。
row格式對于恢復數據有何好處
現在，越來越多場景要求使用row格式的binlog，可以從delete、insert、update三種sql語句角度看待這個問題。
使用delete語句，row格式會把被刪除的行的整行信息保存。所以刪錯之后，只需要把binlog記錄的delete語句轉成insert就能恢復了。
使用insert語句，row格式會記錄所有的字段信息。所以插入錯誤的時候，只需要把binlog記錄的insert語句轉成delete語句就能恢復了。
使用update語句，binlog會記錄修改前整行的數據和修改后的整行數據。所以如果update誤執行，只需要把event前后的兩行信息對調，再去數據庫執行，就能恢復數據了。
M-M結構的循環復制問題以及解決方案
 M-S結構 |  M-M結構 |
圖1是M-S結構，但是現在常用的是M-M結構，M-M結構區別在于：節點A與節點B總是互為主備關系，所以在切換的時候就不用修改主備關系了。
M-M存在循環復制問題：
在節點A更新一個語句，把生成的binlog發給節點B。
節點B執行完更新語句后也會生成binlog。
如果A同時為B的備庫，A會把節點B新生成的binlog拿過去執行。節點A和B之間會不斷循環執行這個更新語句。
解決方案：
已知MySQL在binlog中記錄了命令第一次執行所在實例的server id。
1、規定兩個庫的server id 必須不同。若相同，則不能設定為主備關系
2、備庫接到binlog，生成與原binlog的server id相同的新的binlog
3、每個庫在收到從自己的主庫發過來的日志后，先判斷server id，如果和自己的相同，表示這個日志是自己生成的，丟棄這個日志。
所以使用M-M結構的日志執行流程如下：
1、從節點A更新的事務，binlog里記錄的都是A的server id
2、傳到節點B執行一次后，節點B生成的binlog的server id 也是A的server id
3、再傳給節點A，A判斷這個server id與自己的相同，不處理這個日志
