資料庫是業務系統的心臟，高可用設計容不得半點馬虎。本文基於《MySQL性能調優與架構設計》第 17 章內容，系統梳理 Master-Slave、Dual Master 級聯、MySQL Cluster、DRBD、RaiDB、共享存儲六大主流高可用方案的架構原理、故障切換流程、在線 DDL 解決思路，並給出利弊對比表與選型建議。
一主多從，Slave 故障僅影響該節點讀請求，Master 及其他 Slave 不受影響。前提：集群整體讀寫能力冗餘 ≥ 1 節點。
| 方案 | 架構 | 切換流程 | 優勢 | 劣勢 |
|---|---|---|---|---|
| Slave 升主 | M → S1,S2,S3 | 1. 檢測 M 故障 2. 選 S1 升主 3. S2,S3 CHANGE MASTER TO 指向新主4. 應用寫入切換 | 無額外硬件成本 | 步驟複雜、Slave 同步進度可能不一致、數據丟失風險、可控性弱 |
| Dual Master (雙主熱備) | M1 ⇄ M2 (單向寫 M1) | 1. VIP 綁定 M1 2. M1 故障 → VIP 漂移到 M2 3. 應用無感切換 | 切換簡單可控、秒級故障轉移、VIP 保證單點寫入 | 需額外 1 台服務器、M2 平時閒置資源浪費 |
生產建議：VIP + Heartbeat/Keepalived/MHA/Orchestrator 自動化故障轉移，避免人工介入延誤。
写入流量
↓
[Master A] ←→ [Master B] (VIP 綁定 A)
↓ ↓
[Slave 1] [Slave 2] ← 級聯復制 (所有 Slave 掛載 Master B)
↓ ↓
[Slave 3] [Slave 4]
故障場景處理：
CHANGE MASTER TO A。優勢：A 有完整 Binlog，可通過 Relay Log 時間戳精準定位復制起點，**零數據丟失**。SET sql_log_bin=0 → B 執行 DDL → 啟動復制。sql_log_bin=0) → VIP 切回 A。核心限制：VIP 切換瞬間寫入不可用；大表 DDL 耗時長需低峰期；集群節點多時操作極其繁瑣。MySQL 8.0+ Instant DDL / 5.7 Online DDL 已大幅緩解此問題。
架構：SQL 節點 + NDB 數據節點，共享無架構。
NoOfReplicas=2 時 4 節點分 2 組，每組存全量數據副本。容錯能力：
現狀：早期全內存限制大，新版支援磁盤數據，但生產案例仍較少，核心業務謹慎評估。
位於文件系統與磁碟之間，捕獲 IO 同步寫本地與遠端。三種協議：
| 協議 | 模式 | 完成標誌 | 可靠性 | 效能 |
|---|---|---|---|---|
| A | 異步 | 本地 TCP Send Buffer 入隊 | 低（掉電丟數據） | 最高 |
| B | 半同步 | 遠端 DRBD 接收到 | 中（遠端掉電丟未落盤） | 中 |
| C | 全同步 | 遠端磁碟落盤完成 | 最高（強一致） | 最低 |
關鍵限制：
| 方案 | 部署複雜度 | 故障切換速度 | 數據一致性 | 運維成本 | 適用場景 |
|---|---|---|---|---|---|
| Master-Slave | 低 | 秒級(需工具) | 最終一致(異步) | 低 | 讀多寫少、非核心業務、預算有限 |
| Dual Master + 級聯 | 中 | 秒級(VIP自動) | 主備可能丟數據 | 中 | 核心業務、需自動故障轉移、可接受極少量丟數據 |
| MySQL Cluster | 高 | 毫秒級(無感) | 強一致(同步) | 高 | 極高可用要求、可接受學習曲線、新版本驗證通過 |
| DRBD (Protocol C) | 中高 | 秒級 | 強一致(塊級同步) | 中高 | 現有系統不改架構、需強一致、可接受單主寫入 |
| 共享存儲 | 高(存儲端) | 秒級 | 強一致 | 極高 | 預算充足、已有 SAN/NAS、傳統核心系統改造 |
沒有銀彈，只有權衡。Dual Master + 級聯 + 自動化故障轉移工具 是目前性價比最高、落地最廣的方案；MySQL Cluster/Group Replication 代表原生強一致未來；DRBD 是存儲層透明高可用的經典選擇。架構設計前，務必明確：RPO/RTO 指標、預算上限、團隊能力、業務讀寫模式、擴展性預期。
