傳統 keepalived + haproxy 僅能解決主庫 VIP 漂移，無法自動處理從庫指向新主、Binlog 位點對齊、多從庫拓撲重組。現代方案採用 GTID (全域事務 ID) + 自動故障轉移工具 (MHA/Orchestrator/ProxySQL) 實現真正的零人工介入主從切換。

一、核心難點：從庫如何自動找到新主？

傳統複制依賴 MASTER_LOG_FILE + MASTER_LOG_POS，主庫切換後檔名與位點改變，從庫無法自動銜接。GTID 透過唯一事務識別符 (UUID:SEQ) 解決此問題。

二、GTID 自動定位原理

-- 從庫只需執行 (無需指定檔名/位點)
CHANGE MASTER TO
  MASTER_HOST='new_master_ip',
  MASTER_PORT=3306,
  MASTER_USER='repl',
  MASTER_PASSWORD='xxx',
  MASTER_AUTO_POSITION=1;  -- 關鍵參數
START SLAVE;

內部流程：

1. IO 線程連接新主，交換 GTID_EXECUTED 集合
2. 新主掃描 Binlog，找到從庫缺失的第一個事務起始位置
3. 從該位置開始傳送 Binlog Event，實現無縫銜接

三、生產級自動故障轉移架構

方案 A：MHA (Master High Availability) - 成熟穩健

• Perl 開發，支援主從、多級從、GTID
• 提供 masterha_manager 監控、masterha_master_switch 切換
• 自動識別最新從庫提升為新主，其餘從庫自動 CHANGE MASTER 指向新主
• 官網：mha4mysql-manager

方案 B：Orchestrator - 視覺化拓撲管理

• Go 語言，Web UI 可視化拓撲、一鍵遷移、自動故障轉移
• 支援 GTID、偽 GTID、多資料中心
• 輕量級、無代理、API 驅動，易整合 CI/CD
• 官網：orchestrator

方案 C：ProxySQL + Keepalived - 輕量級讀寫分離與故障轉移

• ProxySQL 監控後端 MySQL 狀態，自動將流量導向健康節點
• 配合 proxysql_galera_checker 或自定義腳本實現主從切換邏輯
• 適合中小規模、追求簡單架構的團隊

四、完整切換流程示例 (MHA)

# 1. 配置 manager.cnf
[server1]  # 原主
hostname=192.168.1.10
[server2]  # 備主
hostname=192.168.1.11
candidate_master=1

# 2. 啟動監控
masterha_manager --conf=/etc/mha.cnf --remove_dead_master_conf --ignore_last_failover

# 3. 故障發生時自動執行：
#   - 驗證原主確實不可用 (SSH/IPMI 雙重檢查)
#   - 選擇最新從庫 (server2) 提升為主
#   - 在新主執行 RESET MASTER (如需)
#   - 其餘從庫自動 CHANGE MASTER TO MASTER_AUTO_POSITION=1
#   - 更新 VIP/ProxySQL 後端
#   - 發送通知 (Email/Slack/Webhook)

五、關鍵配置前置條件

• 所有節點開啟 GTID：gtid_mode=ON, enforce_gtid_consistency=ON, log_slave_updates=ON
• 統一 server_id、repl 用戶權限、binlog_format=ROW
• 網路互通、SSH 免密 (MHA 需要)、時鐘同步 (NTP)
• 定期演練故障演練 (Game Day)，驗證 RTO < 30 秒

採用 GTID + 自動化工具，將「主庫掛了怎麼辦」從深夜驚魂變為可控、可觀測、可演練的標準運維流程。