MySQL 高可用架構：防止宕機資料遺失的三大核心方案深度解析

對於核心業務，MySQL 往往是最關鍵的資料中樞。如何在 Master 宕機時做到 資料零/極小損失、秒級故障感知、自動故障轉移，是架構師必須攻克的難題。本文結合實戰經驗，系統剖析 Replication (複寫)、Monitor (監控)、Failover (故障轉移) 三大支柱的演進與最佳實踐。

一、Replication：資料冗餘的基石與演進

1. 非同步複寫 — 預設模式的風險

MySQL 預設採用 Asynchronous Replication：Master 提交事務後即返回客戶端，不等待 Slave 接收並應用 Binlog。網路抖動、Slave 延遲、Master 宕機瞬間，未傳輸的 Binlog 事件將永久丟失，導致資料不一致。

2. 半同步複寫 — 生產環境的標準選擇

Semi-Synchronous Replication 機制：Master 提交事務後，阻塞等待 至少一個支援半同步的 Slave 確認 收到 Binlog 並寫入 Relay Log 後才返回。極大降低資料遺失窗口。

• 性能影響可控：Facebook、Google 生產環境大規模驗證，延遲通常在毫秒級，除非業務量級超越巨頭，否則無需過度擔憂。
• Loss-Less 語義 (MySQL 5.7+)：rpl_semi_sync_master_wait_point = AFTER_SYNC 確保事務提交前已同步到 Slave，進一步逼近「零遺失」。

建議：優先採用半同步複寫 作為基線方案，配合 MASTER_RETRY_COUNT、MASTER_CONNECT_RETRY 優化重連韌性。

3. 強一致方案：Galera Cluster / InnoDB Cluster

若業務絕對不可容忍任何資料遺失 (金融核心帳務等)，可考慮多主同步複寫方案：

• Galera Cluster (PXC)：認證基複寫，多節點同步寫入，強一致性。代碼侵入性強，需評估相容性。
• MySQL InnoDB Cluster (Group Replication)：官方原生方案，基於 Paxos 協議，單主/多主模式，工具鏈完善 (MySQL Shell, Router)。

4. DRBD 方案 — 不推薦

塊設備級同步，切換快但 Split-Brain 風險高、檔案系統層面一致性難保證，MHA 作者已明確不推薦，現代架構中已被淘汰。

二、Monitor：從 Keepalived 到 Zookeeper 的演進

1. 傳統 VIP 方案

Keepalived / Heartbeat + VIP：透過 VRRP 協議實現 VIP 漂移。缺點明顯：

• 健康檢查粒度粗 (通常只檢查 Port 3306 或簡單 SQL)，無法感知「實例掛掉但進程在」 (如鎖死、慢查詢堵塞)。
• 腦裂風險：網路分區導致雙主，需引入仲裁機制。
• 擴展性差：多叢集、多機房管理極其繁瑣。

2. Zookeeper 為中心的新一代監控架構 (作者早期實踐)

架構：每個 MySQL 實例部署 Sidecar Agent，定期 PING 檢測存活，以 Ephemeral Node 註冊到 Zookeeper。

• 三種故障場景統一感知：
  1. 機器掛掉 → Agent 與 ZK 連接斷開
  2. MySQL 掛掉 → Agent 偵測 Ping 失敗，主動斷開 ZK 連接
  3. Agent 掛掉但 MySQL 存活 → ZK 感知 Agent 節點消失
• 事件驅動自動化：ZK ChildrenChanged 事件觸發管控服務執行 Failover/告警/熔斷。
• 優勢：全叢集統一視圖、毫秒級感知、協調多服務聯動 (如 Proxy 更新、DNS 切換)。

挑戰：部署運維複雜度高 (ZK 集群本身需高可用)、應用端資料庫地址感知機制需配合 (Proxy/VIP/Config Center)。

3. 簡單場景回歸：MHA / Orchestrator

若架構較簡單 (單主雙從)，MHA (Master High Availability) 或 Orchestrator 往往是性價比最高的選擇：

• MHA：Perl 實現，成熟穩定，支援半同步、GTID、自動識別最新 Slave 提升、Binlog 補全。
• Orchestrator：Go 實現，Web UI 友善、支援拓撲可視化、重構、Pseudo-GTID 兼容老版本。

三、Failover：核心難題 — 如何精準定位新主庫 Binlog 座標

1. 傳統痛點：檔名 + Position 的模糊匹配

傳統 Failover 需比較候選 Slave 的 Master_Log_File、Read_Master_Log_Pos，選擇「最新」者提升。但將其他 Slave 重新指向新主時，無法精確知道從新主的哪個 Binlog 位置開始同步，易導致資料重複或遺漏。

2. GTID (Global Transaction Identifier) — MySQL 5.6+ 的終極解法

GTID = source_id:transaction_id (UUID:序號)，全域唯一標識事務。

• Failover 邏輯極簡：新主提升後，其他 Slave 執行 CHANGE MASTER TO MASTER_AUTO_POSITION=1，MySQL 內部自動根據 GTID 集合計算差集，精準同步缺失事務。
• 前提：全叢集開啟 GTID_MODE=ON、ENFORCE_GTID_CONSISTENCY=ON、LOG_SLAVE_UPDATES=ON。

MariaDB GTID 實現不同，工具開發需雙重適配 (go-mysql 等庫已支援)。

3. Pseudo-GTID — 兼容 MySQL 5.5/5.6 之前版本的巧妙折中

作者從 Orchestrator** 專案獲得靈感：利用 MySQL Event Scheduler 每 10 秒向特定 View 寫入 UUID，該 DDL 會記錄進 Binlog，形成「偽 GTID 標記」。

CREATE EVENT IF NOT EXISTS meta.create_pseudo_gtid_view_event
ON SCHEDULE EVERY 10 SECOND
DO
BEGIN
    SET @pseudo_gtid := UUID();
    SET @_create_statement := CONCAT('CREATE OR REPLACE VIEW meta.pseudo_gtid_view AS SELECT ''', @pseudo_gtid, ''' AS pseudo_gtid_unique_val FROM dual');
    PREPARE st FROM @_create_statement;
    EXECUTE st;
    DEALLOCATE PREPARE st;
END;