MySQL 高可用架構五大方案深度對比：NDB Cluster、GFS/DRBD HA、主從讀寫分離、功能分離、官方推薦組合

五大高可用方案綜合評估矩陣

方案深度解析

1. MySQL Cluster (NDB Storage Engine)

• 核心：記憶體內資料、同步復制、自動分區、無單點故障
• 硬體需求：全節點資料放記憶體 (RAM ≥ 總資料量 × 2-3)、萬兆網路、Dolphin SCI 卡
• 優勢：真正冗余、線性擴展、自動故障轉移、負載均衡
• 劣勢：成本極高、速度慢 (網路同步開銷)、不支援完整外鍵/觸發器、複雜 SQL 受限
• 適用：電信計費、即時競價、極高可用優於效能

2. GFS/DRBD + Heartbeat (Active/Passive)

• 原理：共享存儲 (GFS 叢集檔案系統 / DRBD 區塊複製) + 心跳監控自動切換
• 單寫特性：同一時間僅一節點掛載寫入，另節點熱備
• GFS 優勢：POSIX 相容、多節點並發掛載 (但 MySQL 僅單掛載)
• DRBD 優勢：標準 Linux 核心模組、無共享存儲硬體、成本較低
• 關鍵：Heartbeat/Linux-HA 實現自動故障切換 (IP 漂移、服務啟動)

3. 主寫多從讀 (Master-Write / Multi-Slave-Read)

• 架構：單主寫入、多從讀取、非同步/半同步復制
• 應用層：寫操作路由至主庫、讀操作負載均衡至從庫
• 優勢：成本可控、讀擴展線性、部署簡單、成熟生態
• 劣勢：寫單點、復制延遲 (秒級)、主庫故障需人工/腳本切換 (MHA/Orchestrator)
• 優化：半同步復制 (rpl_semi_sync_master=ON)、GTID 復制、ProxySQL 讀寫分離

官方推薦組合：DRBD + Replication + Heartbeat ⭐

# 架構拓撲
[主庫 A] ←── DRBD 同步同步 ──→ [備庫 B] (熱備，Active/Passive)
    │                                    │
    └──── 非同步復制 ────→ [從庫 C1, C2, C3...] (讀擴展)

# 故障場景處理
1. A 掛掉 → Heartbeat 偵測 → B 掛載 DRBD → VIP 漂移至 B → 應用無感切換 (秒級)
2. 讀負載高 → 增加從庫 Cx → ProxySQL 自動納入讀寫分離池
3. 災難恢復 → 從庫提升為主 → 重建 DRBD 雙節點

選型決策樹

1. 是否需要 99.999% 可用性 且預算無上限？ → MySQL Cluster
2. 是否為 讀密集型 (讀寫比 > 10:1)？ → 主寫多從讀 (成本效益最佳)
3. 是否有 共享存儲/預算購買 DRBD 雙機 且需 自動故障轉移？ → DRBD + Heartbeat
4. 是否為 核心交易系統 要求 零資料遺失 (RPO=0)？ → 半同步復制 + DRBD 組合
5. 一般 Web 應用、預算有限、可接受秒級 RPO/RTO？ → 主從 + 定時備份 + 手動切換腳本

生產部署關鍵清單

• ✅ 所有節點 MySQL 版本、配置、字元集、時區完全一致
• ✅ GTID 模式啟用 (gtid_mode=ON, enforce_gtid_consistency=ON)
• ✅ 半同步復制配置 (主庫 rpl_semi_sync_master=ON、從庫 rpl_semi_sync_slave=ON)
• ✅ 監控：Seconds_Behind_Master、Slave_IO_Running/Slave_SQL_Running、復制延遲告警
• ✅ 自動故障轉移工具：MHA (Master High Availability)、Orchestrator、ProxySQL
• ✅ 定期演練：主庫故障切換、從庫提升、備份恢復、資料一致性校驗 (pt-table-checksum)