MySQL 負載均衡集群架構設計與常見問題深度分析

現有架構概覽

目前採用 4 層交換機（L4 Switch） 實現讀寫分離與負載均衡：

• 寫入：所有寫操作直接導向 Master
• 讀取：多台 Slave 經由 L4 Switch 負載均衡分發讀請求
• 同步：Master-Slave 採用 MySQL Replication 機制
• 版本：MySQL 4.0.x

       [Master] ---+---> [Slave1] <-+
                   |                |
                   +---> [Slave2] <-+---- L4 Switch (Read) --- User Read
                   |                |
                   +---> [Slave3] <-+
                   |                |
                   +---> [Slave4] <-+
                   |
             L4 Switch (Write)
                   |
              User Write

架構優勢

1. 讀擴展性強：多 Slave 分擔讀壓力，提升並發讀取能力
2. 讀寫分離：寫入壓力不影響讀取效能，反之亦然
3. 高可用性（讀端）：單台 Slave 故障不影響整體讀服務

核心痛點與挑戰

1. Master 單點故障（SPOF）

• 風險：Master 掛掉導致寫服務中斷
• 現有備案：人工將 Slave 升為 Master，但面臨：
  • 切換期間可能丟失資料（非同步複寫延遲）
  • 無法保證 Slave 資料完整性（Relay Log 可能損壞）
• 探討方向：
  • 雙機 HA（Heartbeat/Corosync + DRBD/Shared Storage）效能影響評估
  • MHA（Master High Availability）或 Orchestrator 自動故障轉移
  • 半同步複寫（rpl_semi_sync_master=ON）降低資料丟失風險

2. Master 寫入效能瓶頸

• 單點寫入無法水平擴展
• 解法：垂直拆庫（按業務拆分至多實例）、分庫分表、升級硬體、引入 ProxySQL 讀寫分離

3. Replication SQL Thread 頻繁中斷

• 現象：同步報錯導致 SQL_THREAD 停止，資料落後
• 臨時處理：

  SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
  START SLAVE SQL_THREAD;
  

• 長期隱憂：跳過錯誤導致主從資料不一致，積累差異難以修復
• 根因排查：
  • 主庫執行非決定性 SQL（如 UUID()、NOW()）
  • Schema 不一致（欄位定義、字元集差異）
  • 主鍵衝突、唯一鍵衝突
  • 從庫唯讀未開啟（read_only=ON），誤寫入導致衝突
• 工具輔助：pt-table-checksum、pt-table-sync（Percona Toolkit）檢測與修復不一致

4. 多實例共享單 SQL Thread 問題

• 單機運行多 MySQL 實例，每實例僅一個 SQL Thread 複寫多個資料庫
• 單點故障影響面大：一個複寫錯誤波及該實例下所有專案
• 建議：實例隔離、關鍵業務獨立實例、監控告警細粒度化

演進架構構想：Master 角色漂移與自動化

         [Slave] -+      +-----------+      +---> [Slave] <-+
         [Slave] -+------| L4 Switch |------+---> [Slave] <-+  (Read Pool)
         [Master]-+      +-----------+      +---> [Slave] <-+
                  ||                      (Virtual IP for Write)
                  ||      +-----------------+
                  +------ | L4 Switch (VIP) |
                         +-----------------+

關鍵機制

1. VIP 漂移：Master 故障時，L4 Switch 將寫入 VIP 切換至備選 Slave
2. 從庫無感知：Slave 透過 VIP 連接 Master，切換後無需修改連線資訊
3. 角色狀態機：每台伺服器內建 Agent 監控自身角色，切換時自動執行：
   • 資料完整性檢查（SHOW SLAVE STATUS、Seconds_Behind_Master=0）
   • Binlog 一致性驗證（GTID / Binlog 位點對齊）
   • 自動修復或拒絕切換並報警人工介入
4. 下線 Master 自動修復：故障節點修復後自動加入 Slave 池，或作為新 Master 備份

技術棧建議

• 健康檢查：自研 Agent 或 mysql-monitor、Consul + mysql-exporter
• 切換編排：Orchestrator、MHA、ProxySQL + Keepalived
• F5 iControl 整合：進階流量控制與節點剔除

總結與建議

MySQL 高可用架構演進是系統工程，需結合業務 RPO/RTO、團隊運維能力、基礎設施成熟度綜合規劃。建議以「可觀測性」為起點，逐步引入自動化工具鏈，而非一次性大爆發式重構。