MySQL 高可用架構方案全景解析：從主從到分布式集群

MySQL 高可用架構方案全景解析：從主從到分布式集群

高可用是互聯網服務標配，數據庫層更需兼顧可用性與數據一致性。本文系統總結主流 MySQL 高可用方案，按底層技術分類，分析優缺點與適用場景。

一、共享存儲方案（SAN）

原理： 通過存儲區域網絡實現多服務器共享同一存儲，主庫故障時備庫掛載同一文件系統接管服務。

• 優點： 避免存儲外組件導致數據丟失；部署切換簡單，對應用透明；保證主備強一致。
• 缺點： 共享存儲成單點故障；成本較高。

二、磁盤複製方案（DRBD）

原理： Linux 內核模塊實現塊級同步複製，將主庫寫入同步至備庫磁盤，類似網絡級 RAID1。

• 優點： 切換透明；強一致性。
• 缺點： 寫入性能受影響；擴展性差（通常雙節點）；備庫不可讀，資源浪費。

三、基於 MySQL 主從複製的方案（單點寫）

生產環境主流方案，利用 MySQL 內建複製構建熱備，主庫故障時切換至從庫。按自動化程度分級：

3.1 Keepalived / Heartbeat

架構： 主從各裝 Keepalived，配置虛擬 IP (VIP)，應用訪問 VIP。主庫故障時 VIP 漂移至從庫。

• 優點： 部署簡單；故障快速切換，對應用透明。
• 缺點： 需同網段；檢測機制弱（需自定義腳本）；異步複製下數據可能丟失（可開啟半同步緩解）；Keepalived 自身無 HA。

3.2 MHA (Master High Availability)

原理： Perl 開發，由 Manager 節點監控集群，故障時從宕機主庫抓取 binlog 補償，選最新從庫提升為新主，重建複製鏈路。

Failover 流程： 檢測故障 → 判斷拓撲 → 處理舊主 → 比較位點選新主 → 補充 binlog/relaylog → 新主上線 → 其他從庫重新指向。

• 優點： 開源可二開；最大程度減少數據丟失；支援 VIP 或 DNS 切換。
• 缺點： 無法保證強一致（主庫磁盤損壞時 binlog 不可用）；需至少三節點；大規模集群配置複雜；Manager 自身單點。

3.3 基於 ZooKeeper 的高可用

核心思想： 引入分布式一致性協議解決 HA 軟件自身單點。各 MySQL 節點部署 HA Client 向 ZooKeeper 上報心跳；HA 節點監聽 ZooKeeper 事件，通過分布式鎖協調切換動作，避免腦裂。

• 優點： 整體系統高可用；擴展性極強，支撐大規模集群；主從一致性依賴半同步或 MHA 類補償。
• 缺點： 架構複雜，引入 ZooKeeper 運維成本高。

四、多點寫入集群方案

4.1 PXC (Percona XtraDB Cluster)

基於 Galera 庫，InnoDB 引擎，準同步複製，多節點可讀寫。

• 優點： 寫擴展；數據強一致；自動節點管理；高可用。
• 缺點： 僅支援 InnoDB；全表需主鍵；寫放大問題；高度依賴網絡穩定，不適合跨地域。

4.2 MySQL NDB Cluster

基於 NDB 存儲引擎，特性類似但限制較多，生產較少見。

五、中間件 Proxy 方案

如 MySQL Fabric、Cobar、TDDL。應用連接 Proxy，Proxy 感知後端拓撲，故障自動路由至新主，實現對應用完全透明，並支援分片擴展。

• 優點： 切換透明；擴展性強；跨機房部署。
• 缺點： 組件較新，生產案例少；強一致仍依賴底層半同步與補償。

總結與選型建議

選型核心：業務場景決定架構。小團隊優先 Keepalived/MHA；大規模、強一致、寫擴展需求看 PXC 或 Proxy+ZooKeeper；預算足且追求極簡運維可考慮 SAN。無銀彈，權衡取捨。