MySQL HA 方案 MMM、MHA、MGR、PXC 對比

阿新 • • 發佈：2020-11-24

MySQL高可用架構

MMM

(Multi Master Replication Manager)

資源	數量	說明
主DB	2	用於主備模式的主主複製
從DB	0~N臺	可以根據需要配置N臺從伺服器
IP地址	2n+1	N為MySQL伺服器的數量
監控使用者	1	使用者監控資料庫狀態的MySQL使用者(replication)
代理使用者	1	用於MMM代理端改變read_only狀態

故障轉移步驟：

Slave伺服器上的操作
- 完成原主上已經複製的日誌恢復
- 使用Change Master命令配置新主
主伺服器上操作
- 設定read_only關閉
- 遷移VIP到新主伺服器

優點：

提供了讀寫VIP的配置，試讀寫請求都可以達到高可用
工具包相對比較完善，不需要額外的開發指令碼
完成故障轉移之後可以對MySQL叢集進行高可用監控

缺點：

故障簡單粗暴，容易丟失事務，建議採用半同步複製方式，減少失敗的概率
目前MMM社群已經缺少維護，不支援基於GTID的複製

適用場景：

讀寫都需要高可用的
基於日誌點的複製方式

MHA

（MySQL Master High Availability）

需要資源：

資源	數量	說明
主DB	2	用於主備模式的主主複製
從DB	2~N臺	可以根據需要配置N臺從伺服器
IP地址	n+2	N為MySQL伺服器的數量
監控使用者	1	使用者監控資料庫狀態的MySQL使用者(replication)
複製使用者	1	用於配置MySQL複製的使用者

MHA採用的是從slave中選出Master，故障轉移：

從伺服器：
- 選舉具有最新更新的slave
- 嘗試從宕機的master中儲存二進位制日誌
- 應用差異的中繼日誌到其它的slave
- 應用從master儲存的二進位制日誌
- 提升選舉的slave為master
- 配置其它的slave向新的master同步

優點：

MHA除了支援日誌點的複製還支援GTID的方式
同MMM相比，MHA會嘗試從舊的Master中恢復舊的二進位制日誌，只是未必每次都能成功。如果希望更少的資料丟失場景，建議使用MHA架構。

缺點：

MHA需要自行開發VIP轉移指令碼。
MHA只監控Master的狀態，未監控Slave的狀態

MGR

（MySQL Group Replication）

支援多主模式，但官方推薦單主模式：

多主模式下，客戶端可以隨機向MySQL節點寫入資料
單主模式下，MGR叢集會選出primary節點負責寫請求，primary節點與其它節點都可以進行讀請求處理.

// 檢視MGR的組員
select * from performance_schema.replication_group_members;
// 檢視MGR的狀態
select * from performance_schema.replication_group_member_stats;
// 檢視MGR的一些變數
show variables like 'group%';
// 檢視伺服器是否只讀
show variables like 'read_only%';

優點：

基本無延遲，延遲比非同步的小很多
支援多寫模式，但是目前還不是很成熟
資料的強一致性，可以保證資料事務不丟失

缺點:

僅支援innodb
只能用在GTID模式下，且日誌格式為row格式

適用的業務場景：

對主從延遲比較敏感
希望對對寫服務提供高可用，又不想安裝第三方軟體
資料強一致的場景

Percona的PXC

Percona XtraDB Cluster是MySQL高可用性和可擴充套件性的解決方案, 的特性如下：

同步複製，事務要麼在所有節點提交或不提交。
多主複製，可以在任意節點進行寫操作。
在從伺服器上並行應用事件，真正意義上的並行複製。
節點自動配置。
資料一致性，不再是非同步複製。

優點：

當執行一個查詢時，在本地節點上執行。因為所有資料都在本地，無需遠端訪問。
無需集中管理。可以在任何時間點失去任何節點，但是叢集將照常工作，不受影響。
良好的讀負載擴充套件，任意節點都可以查詢。

缺點：

加入新節點，開銷大。需要複製完整的資料。
不能有效的解決寫縮放問題，所有的寫操作都將發生在所有節點上。
有多少個節點就有多少重複的資料。

	MMM	MHA	MGR	PXC
優點		成熟穩定、對MySQL侵入小、宕機後保證資料一致	原生高可用、資料一致性保證、支援多主	類似MGR
缺點	太舊，2010年後停止維護；僅支援基於binlog的同步不支援；MySQL5.6以後的提供的多執行緒同步技術沒有讀負載的功能主從切換時，容易造成資料丟失；MMM監控服務存在單點故障，避免的監控服務單點，需要自行實現	選主方式過時、需要配合第三方指令碼進行自動切換；管理節點單點；MySQL非同步複製中的資料丟失，不能保證資料強一致性	管理不方便（需配合mysql-shell）	效能損耗大（降低為1/3）、大事務會卡住整個叢集、需要用第三方發行版MySQL