MySQL MHA 高可用架構部署全實錄：環境準備、主從搭建、Manager/Node 安裝、VIP 漂移、故障切換演練

MySQL MHA 高可用架構部署全實錄：環境準備、主從搭建、Manager/Node 安裝、VIP 漂移、故障切換演練

MHA (Master High Availability) 是成熟的 MySQL 主從自動故障切換方案，0-30 秒完成切換，最大程度保證數據一致性。本文記錄基于 CentOS 6、MySQL 5.6、三節點（1主2從）的完整部署實錄。

一、架構規劃

VIP：192.168.0.10/24（eth0:1），由 master_ip_failover 腳本管理。

二、基礎環境準備（全節點）

1. 關閉 SELinux / 防火牆：setenforce 0、iptables -F
2. 安裝 Perl 依賴：yum -y install perl-DBD-MySQL perl-CPAN perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes
3. 配置 SSH 免密互信：

   [mysqld]
   server-id=16803
   log-bin=/data/mysql/data/mysql-bin.log
   binlog_format=mixed
   gtid_mode=ON
   enforce_gtid_consistency=ON
   relay_log_purge=0
   read_only=0  # Slave 運行時 set global read_only=1
   skip-name-resolve
   innodb_flush_log_at_trx_commit=2  # 半同步建議 1，性能妥協 2
   sync_binlog=1

三、主從復制搭建

1. Master 創建復制/監控用戶：

   mysqldump -A --flush-privileges --lock-all-tables --events --routines --triggers --master-data=2 > /backup/full_$(date +%F).sql

2. Slave 導入備份，配置 CHANGE MASTER TO ...，START SLAVE。
3. 關鍵：所有節點（含 Candidate Master）**必須創建相同的 repl1/monitor 用戶**，否則 MHA 檢查報錯 User repl1 does not exist or does not have REPLICATION SLAVE privilege!。
4. Slave 設置 SET GLOBAL read_only=1;（不寫入 my.cnf，便於切主後開寫）。
5. 解決 auto.cnf UUID 衝突：備份恢復後 rm -f /data/mysql/data/auto.cnf 重啟 MySQL 重新生成 UUID。

四、MHA Node 安裝（全節點）

# 需 EPEL 源解決 perl-Log-Dispatch 依賴
rpm -ivh https://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
yum -y install perl-Log-Dispatch perl-Parallel-ForkManager

tar xvf mha4mysql-manager-0.54.tar.gz
cd mha4mysql-manager-0.54
perl Makefile.PL && make && make install
# 安裝路徑：/usr/local/bin/masterha_manager, masterha_check_ssh, masterha_check_repl, masterha_master_switch...

六、MHA 配置文件 /etc/mha/app1/app1.cnf

#!/usr/bin/perl
my $vip = '192.168.0.10/24';
my $key = '1';
my $ssh_start_vip = "/sbin/ifconfig eth0:$key $vip";
my $ssh_stop_vip = "/sbin/ifconfig eth0:$key down";

my ($command, $ssh_user, $orig_master_host, $orig_master_ip, $orig_master_port,
    $new_master_host, $new_master_ip, $new_master_port) = @ARGV;

if ($command eq "stop") {
  system("$ssh_stop_vip");
} elsif ($command eq "start") {
  system("$ssh_start_vip");
} elsif ($command eq "status") {
  # 檢查 VIP 狀態
}
exit 0;

chmod +x /etc/mha/app1/master_ip_failover，並在配置文件取消註釋 master_ip_failover_script。

八、啟動前檢查

# Master 節點
kill -9 $(pidof mysqld)

# 觀察 Manager 日志 /var/log/manager.log
# 關鍵階段：
# 1. 偵測 Master 掛掉 (PING 失敗 + SSH 可達 + Secondary Check 確認)
# 2. Phase 1: Configuration Check
# 3. Phase 2: Dead Master Shutdown (執行 stop VIP 腳本)
# 4. Phase 3: Master Recovery
#    - 選擇 Candidate Master (192.168.0.4)
#    - save_binary_logs 保存 Master Binlog
#    - apply_diff_relay_logs 衝突 Relay Log
#    - 執行 start VIP 腳本
#    - SET GLOBAL read_only=0 ON NEW MASTER
# 5. Phase 4: Slaves Recovery (192.168.0.5 重新 CHANGE MASTER TO 新主)
# 6. Phase 5: New Master Cleanup (RESET SLAVE)
# 完成：Master failover to 192.168.0.4 completed successfully.

十、切換後恢復舊 Master（作為新 Slave 掛載）

1. 修復硬件/OS，啟動 MySQL。
2. 從 Manager 日志提取 CHANGE MASTER TO MASTER_HOST='192.168.0.4', MASTER_LOG_FILE='mysql-bin.000015', MASTER_LOG_POS=120 ...。
3. 舊 Master 執行 CHANGE MASTER TO ...，START SLAVE。
4. SET GLOBAL read_only=1;，SET GLOBAL relay_log_purge=0;。
5. 執行 masterha_check_repl 驗證拓撲，重啟 Manager 監控。

十一、生產環境避坑清單

• ❌ masterha_manager 連續兩次切換間隔 < 8 小時會報錯 Current time is too early to do failover again → 手動 rm /etc/mha/app1/app1.failover.complete（但應排查為何頻繁切換）。
• ❌ Candidate Master 未創建 repl1 用戶 → 切換後其他 Slave 無法同步。
• ❌ VIP 腳本網卡名錯誤（eth0/eth1） → 切換後應用連不上。
• ❌ relay_log_purge=0 未設置 → Relay Log 被自動清理導致無法恢復。
• ✅ 半同步復制 rpl_semi_sync_master=ON + rpl_semi_sync_slave=ON 最大程度保證零數據丟失。
• ✅ 定期演練切換（月度），驗證 RTO/RPO。

MHA 部署看似繁瑣，實則每一步都是為了「數據不丟、服務不停」的工程承諾。