高可用（HA）是互聯網服務標配。衡量標準：3 個 9（年停機 ≤8h）、5 個 9（年停機 ≤5min）。資料庫 HA 需同時兼顧服務可用性與資料一致性。本文系統整理 MySQL 主流 HA 方案，分析優缺點與適用場景。
架構：主備伺服器掛載同一 SAN 存儲，主機故障時備機掛載同一文件系統接管。
| 優點 | 缺點 |
|---|---|
| 避免存儲外組件導致資料遺失 部署/切換簡單，對應用透明 主備強一致 | SAN 單點故障風險 成本高昂 |
架構：Linux 核心模組，區塊級同步複寫，主機寫入同步至備機區塊裝置。
| 優點 | 缺點 |
|---|---|
| 切換透明 強一致 | 寫入效能受影響（同步網路延遲） 通常雙節點，擴展性差 備庫不可讀，資源浪費 |
架構：VIP 漂移，Keepalived 監聽主庫健康狀態，故障時提升從庫為主。
| 優點 | 缺點 |
|---|---|
| 安裝簡單 故障快速切換，應用透明 | 主備需同網段 檢測機制弱，需自訂腳本（如心跳表） 異步複寫無法保證強一致，可開啟半同步緩解 Keepalived 自身 HA 無保障 |
架構：Manager 節點 + Data 節點，故障時從故障主庫保存 binlog 回補，最大程度減少資料遺失。
| 優點 | 缺點 |
|---|---|
| 開源可二次開發 修復多從庫差異，選最新數據節點為新主 支援 VIP 或全域目錄庫切換 | 無法保證強一致（主庫磁碟損壞/SSH 失效時 binlog 不可取） 僅支援一主多從，至少三節點 全域目錄庫切換對應用不透明 大規模叢集部署複雜 Manager 自身 HA 無保障 |
架構：每個 MySQL 節點部署 HA Client 向 ZooKeeper 上報心跳，HA 節點監聽 ZooKeeper 事件，透過分散式鎖保證單一切換動作。
| 優點 | 缺點 |
|---|---|
| 整體系統高可用（含 HA 自身） 強一致依賴 MySQL 半同步或 MHA 回補 擴展性極佳，支援大規模叢集 | 引入 ZooKeeper 系統複雜度大幅提升 |
| 優點 | 缺點 |
|---|---|
| 準同步複寫 多節點可讀寫，寫擴展 自動節點管理 資料嚴格一致 服務高可用 | 僅支援 InnoDB 所有表必須有主鍵 寫入放大（同步至所有節點） 高度依賴網路穩定，不適合跨機房遠距離同步 |
基於 NDB 引擎，限制較多，生產較少採用。
代表：MySQL Fabric、阿里 Cobar/TDDL、MySQL Proxy。
| 優點 | 缺點 |
|---|---|
| 切換對應用透明 擴展性強，便於分片 支援跨機房部署切換 | 較新組件，生產案例少 未解決強一致，依賴 MySQL 半同步與回補機制 |
主從複寫方案最成熟主流；引入中間件/ZooKeeper 可提升可用性與規模，但對研發運維要求更高。選型需依業務場景與運維能力抉擇。
