MMM與MHA以及MGR，高可用架構都有如下的共同點：
- 對主從複製集羣中的Master節點進行監控
- 自動的對Master進行遷移，通過VIP。
- 重新配置集羣中的其它slave對新的Master進行同步
一、MMM
需要兩個Master，同一時間只有一個Master對外提供服務，可以說是主備模式。
需要基礎資源：
故障轉移步驟：
- Slave服務器上的操作
- 完成原主上已經複製的日誌恢復
- 使用Change Master命令配置新主
- 主服務器上操作
- 設置read_only關閉
- 遷移VIP到新主服務器
優點：
- 提供了讀寫VIP的配置，試讀寫請求都可以達到高可用
- 工具包相對比較完善，不需要額外的開發腳本
- 完成故障轉移之後可以對MySQL集羣進行高可用監控
缺點：
- 故障簡單粗暴，容易丟失事務，建議採用半同步複製方式，減少失敗的概率
- 目前MMM社區已經缺少維護，不支持基於GTID的複製
適用場景：
- 讀寫都需要高可用的
- 基於日誌點的複製方式
二、MHA
需要資源：
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)
- 讀寫分離
關於寫負載大：
- 分庫分表
- 增加中間層