MySQL 高可用 (HA) 架構方案全景解析：從主從到分叢集的演進選型
MySQL 原生不提供自動故障轉移，生產環境高可用需結合複製架構 + 代理中間層 + 故障檢測/切換工具。本文系統梳理主流 HA 方案優劣與選型建議。
核心 HA 架構模式對比
| 方案 | 架構 | 故障轉移 | 資料一致性 | 讀寫分離 | 複雜度 | 適用場景 |
|---|
| MHA (Master High Availability) | 一主多從 + Manager 節點 | 自動 (秒級) | 半同步/非同步 | 需外掛 Proxy | 中 | 中小規模、成熟穩定首選 |
| MGR (MySQL Group Replication) | 多主/單主叢集 (3+ 節點) | 自動 (Paxos 協議) | 強一致 (多主最終一致) | 原生支援 | 高 | MySQL 5.7+/8.0、高一致性需求 |
| Orchestrator | 拓撲管理 + 外部 Proxy | 自動/手動 | 依複製模式 | 需外掛 Proxy | 中 | 大規模拓撲管理、遷移重構 |
| Galera Cluster (PXC) | 多主同步叢集 (WSREP) | 自動 | 強一致 | 原生支援 | 高 | 寫入擴展、跨資料中心 |
| ProxySQL + Keepalived/VIP | 代理層 + 主從 | 腳本/外部工具觸發 | 依複製模式 | 原生支援 | 中 | 需精細流控、讀寫分離 |
| DRBD + Heartbeat/Corosync | 雙節點共享存儲 | 自動 (資源代理) | 強一致 (塊級同步) | 單點寫入 | 高 | 傳統雙機熱備、存儲層 HA |
關鍵技術組件選型
複製模式
- 非同步：效能最好，風險主庫故障丟失未同步事務
- 半同步 (rpl_semi_sync)：主庫等待至少 1 從庫 ACK，平衡效能與安全，**生產強烈推薦**
- GTID 複製：事務全域唯一 ID，簡化故障切換定位，**現代 HA 基石**
代理與路由層
- ProxySQL：高效能、支援查詢重寫、熔斷、讀寫分離、連線池，**首選**
- MaxScale：MariaDB 官方、功能豐富、企業級支援
- HAProxy/Keepalived/VIP：傳統四層代理，簡單可靠
故障檢測與自動切換
- MHA Manager：SSH+SQL 雙重檢測、自動提升最新從庫、Binlog 補償
- Orchestrator：Web UI 視覺化拓撲、自動修復、遷移工作流
- 自研腳本 + Consul/Etcd：輕量級、服務發現整合
生產部署核心清單
- 最小 3 節點：滿足多數派遷、避免腦裂
- 半同步 + GTID：資料零丟失 (視超時策略) + 簡單切換
- ProxySQL 讀寫分離：應用無感知、支援權重路由、慢查詢熔斷
- 監控告警體系：
Seconds_Behind_Master、Slave_IO/SQL_Running、磁碟/CPU/連線數
- 定期演練：每季模擬主庫掛掉、網路分區、誤刪資料等故障演練
- 備份策略：每日全備 + Binlog 增備、異地存儲、定期恢復演練
避坑指南
- ❌ 單主單從無代理：故障需人工介入，RTO 不可控
- ❌ 非同步複製核心業務：主庫故障必丟資料
- ❌ 忽略網路分區：需配置
network_timeout、heartbeat_period 避免誤判
- ❌ 無備份驗證：備份不可用等於無備份
- ✅ 選型原則：業務容忍 RPO/RTO → 架構複雜度 → 團隊運維能力 三角權衡
雲原生趨勢
Kubernetes 環境下，推薦使用 Operator 模式：
- Oracle MySQL Operator / Presslabs MySQL Operator / Vitess
- 原生支援：備份排程、時間點恢復 (PITR)、滾動升級、分片管理
- 結合 CSI 存儲快照 實現秒級克隆與恢復
