MySQL 高可用技術對比:復制、MHA、MGR、Galera、ProxySQL 選型指南
MySQL 高可用方案按可用性等級分層:99.9% (基礎復制) → 99.99% (MHA/Orchestrator) → 99.999% (MGR/Galera/Geo-Redundancy)。本文基於姜承堯《MySQL 技術內幕》體系,對比主流方案架構、切換時間、數據一致性、運維複雜度,附選型決策樹。
可用性等級與允許停機時間
| 等級 | 年停機時間 | 典型方案 |
| 99.9% (兩個 9) | 8.76 小時 | 主從復制 + Keepalived/VIP |
| 99.99% (四個 9) | 52.6 分鐘 | MHA、Orchestrator、ProxySQL + GTID |
| 99.999% (五個 9) | 5.26 分鐘 | MGR (InnoDB Cluster)、Galera Cluster、異地多活 (Geo-Replication) |
主流方案深度對比
| 方案 | 架構 | 切換時間 | 一致性 | 寫入延遲 | 運維複雜度 | 適用場景 |
| 主從復制 | 异步/半同步 | 秒級-分鐘級 (需外部腳本) | 最終一致 (异步可能丟數據) | 低 | 低 | 讀寫分離、備庫、延遲從庫防誤刪 |
| MHA | Manager + 多節點 | 10-30 秒 | 半同步可保證無丟失 (rpl_semi_sync_master_wait_point=AFTER_SYNC) | 低 (半同步 RTT) | 中 | 傳統高可用、MySQL 5.6/5.7 主流 |
| Orchestrator | 拓撲管理 + 自動故障轉移 | 秒級 | 同主從 | 低 | 中 | 大規模集群拓撲可視化、遷移、故障轉移 |
| MGR (Group Replication) | 多主/單主 組複制 (Paxos 變體) | 毫秒級 (組員自動選主) | 強一致 (多主衝突檢測) | 中 (組通信開銷) | 中高 | 8.0+ 原生高可用、InnoDB Cluster、金融核心業務 |
| Galera Cluster (PXC) | 同步多主 (wsrep/GComm) | 毫秒級 | 強一致 (認證失敗回滾) | 高 (寫入需所有節點認證) | 高 | 多寫入點、跨數據中心同步、高一致性要求 |
| ProxySQL | SQL 感知代理 (路由/熔斷/緩存/鏡像) | 配合上層方案 | 透傳 | 極低 (用戶態) | 中 | 讀寫分離、查詢重寫、熔斷限流、平滑遷移 |
| DRBD | 塊級網絡鏡像 (RAID-1 over Network) | 秒級 (心跳+掛載) | 強一致 (同步模式) | 高 (網絡 RTT) | 中 | 兩節點共享存儲替代、無共享存儲環境 |
關鍵技術點解析
- 半同步復制:
rpl_semi_sync_master_wait_point=AFTER_SYNC (5.7+) 保證主庫事務提交前至少一從庫收到 Binlog 並刷盤,極大降低丟數據風險。
- GTID (Global Transaction ID):
GTID = source_id:transaction_id,簡化故障轉移時的 Binlog 定位,MHA/Orchestrator/MGR 均強依賴 GTID。
- MGR 組通信:基於
XCom (Paxos 變體),單主模式無寫入衝突,多主模式需應用層避免熱點主鍵衝突。
- Galera 流控:
wsrep_flow_control_paused 監控,寫入熱點導致流控頻繁觸發時需拆分熱點表或調整 gcs.fc_limit。
- 異地多活 (Geo-Replication):GlusterFS/DRBD/存儲層複制 + 數據庫層異步復制,RPO≈0、RTO≈分鐘級,成本極高,僅核心交易/賬戶系統採用。
選型決策樹
- 業務能容忍秒級丟數據、分鐘級恢復? → 主從復制 + 定期備份 + 延遲從庫。
- 需自動故障轉移、無丟數據、MySQL 5.6/5.7? → MHA + 半同步 + GTID + ProxySQL 讀寫分離。
- MySQL 8.0、原生高可用、強一致、運維團隊有 DBA? → MGR (InnoDB Cluster) + MySQL Router/ProxySQL。
- 多寫入點、跨 IDC 同步、極高一致性? → Galera Cluster (PXC) + ProxySQL。
- 雲原生、Kubernetes? → Operator (Oracle MySQL Operator、Presslabs、Vitess) 托管 MGR/Galera。
高可用不是堆疊組件,而是「檢測 → 決策 → 切換 → 驗證 → 恢復」閉環的工程體系。核心指標:RTO (恢復時間目標)、RPO (恢復點目標)、切換成功率、數據零丟失。選型前必須做混沌工程演練 (殺主、斷網、磁盤慢、CPU 滿) 驗證方案邊界。