目錄

• • 備庫為什么要設置為只讀模式？
  • 備庫設置為只讀，如何與主庫保持同步更新？
  • 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與自己的相同，不處理這個日志

總結

以上是生活随笔為你收集整理的《MySQL——主备一致性六问六答》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。