高可用核心指標
- 可靠性：資料不丟失（如銀行核心系統）。
- 可用性：服務持續對外提供（如電商前台）。
- 可用性等級與允許停機時間：
七大主流高可用方案對比
方案一：標準主從複制（單活）
- 優點：架構簡單，從庫可分擔讀流量、備份。
- 缺點：主庫故障需外部工具（MHA、Orchestrator）自動切換；主庫寫入延遲可能導致資料丟失。
- 適用：99.9% 可用性需求。
方案二：雙主單活
- 優點：切換邏輯較單主簡化（MMM 腳本）。
- 缺點：其中一主掛掉，其下掛掛的從庫同樣不可用。
方案三：雙主 + SAN 共享存儲（單活）
- 優點：兩主共享同一儲存，無複制延遲，切換快，從庫不受影響。
- 缺點：SAN 成本極高（有錢人方案），單點風險轉移到存儲層。切換後無預熱，效能短暫下降。
方案四：雙主 + DRBD（單活）
- 優點：本地磁碟同步複制，成本低，被稱為「窮人的 SAN」。
- 缺點：同步寫入有效能損耗；Split-brain 風險需配置仲裁機制。
方案五：MySQL NDB Cluster
- 特點：官方原生共享無架構，資料節點自動分片與冗餘，強一致性，無第三方依賴。
- 缺點：運維複雜，JOIN 跨分片效能差，不支援外鍵、全文索引等特性。國內僅少數銀行採用。
- 適用：99.99%~99.999% 可用性。
方案六：Tungsten Replicator（第三方）
- Java 開發，支援異構複制（MySQL → Oracle、Kafka 等）。
- 適合跨資料庫同步場景，非 MySQL 專屬高可用首選。
方案七：網易 InnoSQL（類 SQL Server 鏡像高安全模式）
- 核心：半同步複制 + 強一致性讀取。主庫事務需等待從庫確認才提交，確保零資料丟失。
- 差異：InnoSQL 從庫可讀，SQL Server 鏡像從庫不可讀。
- MySQL 5.7+ 官方已支援類似模式（
rpl_semi_sync_master_wait_for_slave_count=1）。
選型建議
| 業務等級 | 推薦方案 | 成本 | 關鍵風險 |
|---|
| 中小型、可容忍分鐘級 RPO | 主從 + MHA/Orchestrator | 低 | 主庫單點、複制延遲 |
| 核心交易、零資料丟失 | InnoSQL / MySQL 5.7+ 半同步 | 中 | 主庫寫入延遲增加 |
| 極高可用、跨機房容災 | NDB Cluster + Geo-Replication | 高 | 運維複雜、SQL 限制多 |
| 預算充足、追求簡單切換 | 雙主 + SAN / DRBD | 高/中 | 存儲單點、Split-brain |
延伸閱讀
- 讀寫分離中間件：Amoeba、ProxySQL、MyCat。
- 異地災備：Gluster Geo-replication 原理與部署。
- 資料庫集群技術漫談。
各方案各有優劣，DBA 需結合業務 RPO/RTO、預算、團隊能力綜合選型。
