防止 MySQL 數據丟失的高可用架構演進：從異步復制到 Galera、ZooKeeper 監控
MySQL 作為核心數據中台，其高可用（HA）能力直接決定業務連續性。本文梳理從基礎復制到企業級 HA 方案的演進路徑，涵蓋半同步復制、Galera Cluster、DRBD、ZooKeeper 監控體系的技術選型與落地經驗。
一、Replication 基石與數據安全痛點
異步復制（預設）
- Master 提交事務後不等待 Slave 確認即返回客戶端。
- 優點：延遲低、性能高。
- 缺點：Master 宕機時，未傳輸至 Slave 的事務永久丟失（RPO > 0）。
半同步復制 —— 生產環境首選平衡點
- Master 等待至少一個半同步 Slave 確認收到 Relay Log 並持久化後才提交返回。
- 數據安全性大幅提升（RPO ≈ 0），性能影響可控（Facebook 生產驗證）。
- MySQL 5.7+ 引入 Loss-Less Semi-Sync：Master 等待 Slave 寫入 Relay Log 並 Flush 到磁盤後再提交，進一步縮小丟數據窗口。
# Master 配置
rpl_semi_sync_master_enabled = 1
rpl_semi_sync_master_timeout = 1000 -- 超時回退異步(ms)
# Slave 配置
rpl_semi_sync_slave_enabled = 1
Galera Cluster（PXC/MariaDB Cluster） —— 強一致「三寫」
- 同步多主架構，通過 認證機制 保證節點間數據強一致。
- 寫入需過半數節點確認，單節點故障零數據丟失。
- 代價：寫入延遲隨網絡 RTT 增加，大事務/熱點行衝突明顯，對應用有一定侵入性（需無鎖表、主鍵必須、不支援 LOCK TABLES 等）。
DRBD（Distributed Replicated Block Device） —— 塊級同步
- 內核模塊將磁盤塊級同步至備機，MySQL 感知不到復制邏輯。
- 優點：對應用完全透明，支持任意文件系統。
- 缺點：Split-brain 風險、故障切換需外部仲裁、性能受網絡/磁盤雙重制約。MHA 作者曾指出生產坑較多，現較少推薦作為首選。
二、Monitor：故障發現的「神經系統」
傳統方案：Keepalived / Heartbeat
- 基於 VIP 漂移實現主備切換，成熟簡單。
- 缺點：僅能感知網絡/進程存活，無法檢測 MySQL 邏輯故障（如卡死、只讀、復制延遲極大）。
現代方案：ZooKeeper + Agent 架構
架構設計：
- 每個 MySQL 實例部署一個 Sidecar Agent（同主機）。
- Agent 定期執行
SELECT 1 / SHOW SLAVE STATUS 健康檢查。
- Agent 以 Ephemeral Node 註冊至 ZooKeeper（
/mysql/cluster-name/host:port）。
- Controller 監聽 ZK 節點變更事件，觸發自動 Failover 或告警。
三種故障場景判定
| 場景 | Agent 狀態 | ZK 事件 | 處理邏輯 |
|---|
| MySQL 進程掛掉 | 檢查失敗 | Node 刪除 | Controller 觸發自動 Failover |
| 主機宕機/網絡分區 | 心跳斷開 | Session 過期，Node 刪除 | Controller 觸發自動 Failover |
| Agent 自身異常 | 進程退出 | Node 刪除 | 依賴 crontab/systemd 重啟 Agent，不觸發 DB Failover |
ZK 方案優勢
- 集群級全局視圖，單點故障不影響整體決策。
- 事件驅動，毫秒級感知，配合 Controller 實現秒級 Failover。
- 天然支援多機房、多集群統一管控。
挑戰與對策
- 部署複雜度：引入 Docker 容器化部署 Agent+MySQL，標準化鏡像，極大降低運維門檻。
- 應用端地址感知：VIP、DNS 變更、配置中心動態推送、Proxy（ProxySQL/MaxScale）中間層透明路由。
- 小規模集群：單主單備場景 Keepalived 仍是性價比最高選擇，無需上 ZK。
三、綜合架構建議
| 業務級別 | 推薦方案 | 核心理由 |
|---|
| 一般業務（可容忍秒級 RPO） | 異步復制 + Keepalived | 簡單、成熟、性能無損耗 |
| 核心業務（要求 RPO≈0、RTO<30s） | 半同步復制 + Orchestrator/MHA + ProxySQL | Facebook 級驗證、工具鏈成熟、運維友好 |
| 金融/交易核心（強一致、零容忍） | Galera Cluster (PXC) + ProxySQL | 同步多主、自動成員管理、零數據丟失 |
| 超大規模、多機房 | 半同步/Galera 混合 + ZooKeeper 管控平台 | 統一元數據、跨區域故障域隔離、自動化運維 |
總結
「沒有銀彈，只有權衡」。理解復制模式對 RPO/RTO 的本質影響，結合業務價值、團隊運維能力、基礎設施成熟度選型。半同步復制 + 自動化故障轉移工具 是絕大多數互聯網核心業務的「最佳性價比」落點；Galera 為強一致剛需保留；ZooKeeper/K8s Operator 則是向平台化、自動化演進的必經之路。
