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 |
限制與不足
-
僅支持InnoDB表，並且每張表一定要有一個主鍵，用於做write set的沖突檢測；
-
必須打開GTID特性，二進制日志格式必須設置為ROW，用於選主與write set
-
COMMIT可能會導致失敗，類似於快照事務隔離級別的失敗場景
-
目前一個MGR集群最多支持9個節點
-
不支持外鍵於save point特性，無法做全局間的約束檢測與部分部分回滾
-
二進制日志不支持binlog event checksum
參考
https://juejin.cn/post/6844903812700831752
https://tech.meituan.com/2017/06/29/database-availability-architecture.html
https://cloud.tencent.com/developer/article/1054465
https://www.zhihu.com/question/53617036/answer/135776740
https://juejin.cn/post/6844903785848897543
https://www.talkwithtrend.com/Question/416891-2877659
https://my.oschina.net/Declan/blog/3114672