MMM與MHA以及MGR，高可用架構都有如下的共同點：

• 對主從復制集群中的Master節點進行監控
• 自動的對Master進行遷移，通過VIP。
• 重新配置集群中的其它slave對新的Master進行同步

MMM

需要兩個Master，同一時間只有一個Master對外提供服務，可以說是主備模式。

需要基礎資源：

資源數量說明

主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

需要資源：

資源數量說明

主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

MGR是基于現有的MySQL架構實現的復制插件，可以實現多個主對數據進行修改，使用paxos協議復制，不同于異步復制的多Master復制集群。

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

• 多主模式下，客戶端可以隨機向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格式

適用的業務場景：

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

讀寫負載大問題

讀負載大：

• 增加slave

• 加中間層(MyCat，ProxySQL，Maxscale)

• 讀寫分離

關于寫負載大：

• 分庫分表
• 增加中間層

最后

參考慕課網課程，s.imooc.com/S8KFBvs

轉載于:https://juejin.im/post/5ca4b5dcf265da30bf15d096

總結

以上是生活随笔為你收集整理的MySQL高可用架构对比的全部內容，希望文章能夠幫你解決所遇到的問題。

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