主備切換

主備流程圖

主庫的後臺執行緒通過長連線將binlog日誌同步到從庫，從庫的io_thread接受binlog寫入從庫的redo log ，從庫的sql_thread執行緒重放redo log 到資料庫。

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 讀取中轉日誌，解析出日誌裡的命令，並執行。

其他

為什麼要將備庫設定為只讀模式

強烈將備庫設定為只讀模式。

原因有三

1. 運營類的查詢會放到備庫執行，防止誤操作
2. 防止切換過程中出現雙寫，造成主備不一致
3. 用readonly狀態，判斷節點的角色

binlog 三種格式的不同

binlog有三種格式，statement, row, mixed

1. statement, 當 binlog_format=statement 時，binlog 裡面記錄的就是 SQL 語句的原文
2. row格式會記錄操作的記錄的主鍵ID，還有預設所有的欄位, binlog_row_image=FULL
   會記錄操作記錄的所有欄位，設定binlog_row_image=MINIMAL,則只會記錄必要的資訊。
3. mixed, 是mysql 折衷了statement和row兩種格式，mixed 格式的意思是，MySQL 自己會判斷這條 SQL 語句是否可能引起主備不一致，如果有可能，就用 row 格式，否則就用 statement 格式。

xid event
redo log 和 binlog 是怎麼關聯起來的? 回答：它們有一個共同的資料欄位，叫 XID。崩潰恢復的時候，會按順序掃描 redo log：如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；如果碰到只有 parepare、而沒有 commit 的 redo log，就拿著 XID 去 binlog 找對應的事務。

設定binlog格式為ROW格式， 的一個好處是方便恢復資料。。MariaDB 的Flashback工具就是基於上面介紹的原理來回滾資料的。

雙M 如何防止binlog 迴圈複製

1. 兩個庫的server_id 必須不同，如果相同，不能互為主備
2. 備庫執行主庫生成的從庫binlog，server_id 設定為主庫的server_id
3. 每個庫收到主庫的日誌後，如果binlog的server_id 與 自身相同，則表示日誌原來是自己生成的，直接丟棄掉。

檢視binlog 相關命令

-- 檢視bin_log格式
show variables like 'binlog_format';
-- 檢視是否開啟了bin_log
show variables like 'log_bin';
-- 檢視master上日誌
show master logs;
-- 檢視正在寫入的binlog檔案
show master status ;