MHA GTID 模式故障切換源碼流程深度解析：從檢測到恢復全鏈路

GTID 模式啟用條件

MHA 判斷為 GTID 模式需同時滿足：

1. 所有節點 gtid_mode=ON
2. 所有節點 Executed_Gtid_Set 非空
3. 至少一個節點 Auto_Position=1

故障切換五大階段

Phase 1: 配置檢查階段

• check_settings：版本檢查、連通性驗證
• get_dead_servers/get_alive_servers/get_alive_slaves：雙重確認節點存活
• start_sql_threads_if：確保 SQL 線程運行

Phase 2: 故障主庫關閉階段

• force_shutdown：停止所有 Slave IO 線程（含故障主庫）
• 執行 master_ip_failover_script（VIP 漂移）、shutdown_script

Phase 3: 主庫恢復階段（核心）

3.1 獲取最新 Slave

• read_slave_status：收集 Master_Log_File、Read_Master_Log_Pos、Executed_Gtid_Set 等
• identify_latest_slaves：按 Relay_Master_Log_File/Exec_Master_Log_Pos 找最新
• identify_oldest_slaves：找最舊（用於差量補全）

3.2 選主邏輯

get_most_advanced_latest_slave() // Relay_Master_Log_File/Exec_Master_Log_Pos 最前
select_new_master():
  1. 優先 preferred_master（配置 candidate_master=1）
  2. 排除：死節點、no_master、log_bin=OFF、版本不一致、延遲>1億
  3. 兜底策略：最新 relay → 所有 candidate → 所有 slave

3.3 新主恢復

recover_master_gtid_internal():
  wait_until_relay_log_applied()          // 等待 SQL 線程追上
  stop_slave()
  if (new_master != latest_slave) {
    latest_slave.wait_until_relay_log_applied()
    change_master_and_start_slave(new_master, latest_slave)
    wait_until_in_sync(new_master, latest_slave)
  }
  save_from_binlog_server()               // 從 binlog server 取缺失 binlog
  apply_binlog_to_master()                // 應用補全 binlog
  master_ip_failover_script --command=start  // 啟用 VIP
  set read_only=0 (unless skip_disable_read_only)

Phase 4: Slave 恢復階段

recover_slaves_gtid_internal():
  // 並行執行
  foreach slave:
    change_master_and_start_slave(slave, new_master)
  if (wait_until_gtid_in_sync):
    SELECT WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(gtid_set, 0)

Phase 5: 新主清理階段

• reset_slave_on_new_master：RESET SLAVE ALL 清理原 Slave 信息，完成角色轉換

在線切換

GTID 模式下在線切換流程與非 GTID 一致，僅 CHANGE MASTER TO 語法改為 MASTER_AUTO_POSITION=1，此處省略。