大家好，我是君哥。

雙主架構是 MySQL 常見的一種架構模式，它的特點是有兩個主節(jié)點對外提供服務，并且這兩個主節(jié)點互為主備。今天來學習一下雙主架構。

1.雙主復制

這種架構的特點配置兩個主庫，每個主庫都提供讀寫服務，并且這兩個主庫互為主備。如下圖：

在 M1 寫入的數(shù)據(jù)要同步到 M2，在 M2 寫入的數(shù)據(jù)要同步到 M1。這種兩個主庫同時支持寫入，這種架構模式一個明顯的優(yōu)勢寫入效率高。比如一個應用在不同的城市部署了兩個主節(jié)點，請求可以就近選擇寫入數(shù)據(jù)庫。

但這種架構在數(shù)據(jù)同步時很容易出問題。

案例一：M1 和 M2 同時收到一張表的插入請求，這張表是自增主鍵，兩張表插入后主鍵相同。這時發(fā)生數(shù)據(jù)同步，這條插入語句在 binlog 里面記錄的是 row 格式，同步時發(fā)生主鍵沖突。

MySQL binlog 有三種格式：

• STATEMENT：記錄的是 SQL 語句本身；
• ROW：記錄的是數(shù)據(jù)的變化；
• MIXED：STATEMENT 和 ROW 格式的結合，MySQL 會根據(jù) SQL 語句特性選擇使用 STATEMENT 還是 ROW 格式。

MySQL 5.0 后可以通過設置 auto_increment_increment 和 auto_increment_offset 這兩個選項來解決這個問題。

案例二：在 M1 上執(zhí)行了一條語句，生成 binlog 后發(fā)給 M2 進行同步，M2 執(zhí)行完成后又生成 binlog 同步給 A，導致一條語句循環(huán)復制。

這個問題的解決方法是要求 M1 和 M2 的 server id不相同，M1 產(chǎn)生的 binlog 記錄 server id 是 M1，M2 執(zhí)行同步時生成的 binlog 也記錄 server id 為 M1。這樣同步給 M1 是，M1 判斷到 server id 跟自己相同，就丟棄這個日志，不做同步。

案例三：同步過程中會有數(shù)據(jù)不一致的問題。比如用戶 xiaoming 的賬戶余額是 100。M1 執(zhí)行了 update 操作把賬戶余額更新成 150，M2 執(zhí)行了 update 操作更新成 130。

解決這種數(shù)據(jù)不一致問題的一個思路是嚴格劃分數(shù)據(jù)和設置權限，比如案例中小明的所有數(shù)據(jù)只能在 M1 上操作。

案例四：因為節(jié)點發(fā)生故障，M1 不能復制了，但是應用可以寫數(shù)據(jù)庫，M2 能正常寫和復制，這個問題就很難解決了。

解決這個問題，需要給 M1 和 M2 配置從節(jié)點，主節(jié)點故障后切換到從節(jié)點進行工作。

2.主備復制

這個架構模式的特點是雙主節(jié)點中，同一時刻只有一個主節(jié)點提供寫服務，另一個主節(jié)點只能提供讀服務。如下圖：

這個架構相當于比單主節(jié)點架構多了一個熱備，有如下優(yōu)勢：

• 因為 M1 和 M2 配置對稱，切換主備比較容易；
• 有助于故障轉移和恢復；
• 可以在不影響應用的情況下進行數(shù)據(jù)庫升級和維護；
• 不用考慮循環(huán)復制問題和主備不一致問題。

當然，主備架構也有缺點，那就是寫性能不能得到提升。

3.主主架構擁有備庫

主主架構中每個主庫也可以擁有備庫，如下圖：

這種配置為每個主庫增加了一個備份，可以防止單點故障，同時備庫也可以處理讀請求，提高數(shù)據(jù)庫整體讀效率。

這個架構的缺點是增加了機器成本。

4.環(huán)形復制

環(huán)形復制架構是 MySQL 集群中擁有多個主庫，主庫之間形成一個環(huán)形，前面一個節(jié)點是當前節(jié)點的主庫，當前節(jié)點是前面節(jié)點的備庫，也是后面一個節(jié)點的主庫。如下圖：

環(huán)形復制這種架構其實并不推薦，因為它很難做到故障轉移，高可用特性依賴于每個節(jié)點不出故障。但是如果一個節(jié)點出了故障，去掉這個節(jié)點，這個節(jié)點產(chǎn)生的 binlog 將一直循環(huán)復制下去，因為只有通過這個節(jié)點的 server id 才能做出判斷停止復制。

5.總結

本文介紹了 MySQL 雙主架構的多種復制架構，雙主架構需要注意解決循環(huán)復制、單點故障問題，同時做好數(shù)據(jù)權限劃分。