MySQL高可用架构实战：主从复制与MHA自动故障切换部署

数据库高可用架构的核心诉求是主库故障后业务不中断。以MySQL 8.0为例，主从复制搭建数据冗余，MHA负责自动故障切换，配合VIP漂移完成应用无感切换。本文给出从复制搭建到切换验证的完整部署过程，并讨论脑裂与数据一致性防护。

MySQL主从复制：GTID模式搭建

GTID复制让主从追踪binlog位置关系，维护成本低得多。主库配置：

[mysqld]
server-id = 1
gtid_mode = ON
enforce_gtid_consistency = ON
log_bin = mysql-bin
binlog_format = ROW

从库配置：

[mysqld]
server-id = 2
gtid_mode = ON
enforce_gtid_consistency = ON
relay_log = mysql-relay
read_only = ON

主库导出导入数据后执行：

CHANGE MASTER TO
  MASTER_HOST='192.168.1.10',
  MASTER_PORT=3306,
  MASTER_USER='repl',
  MASTER_PASSWORD='xxx',
  MASTER_AUTO_POSITION=1;
START SLAVE;

验证Slave_IO_Running与Slave_SQL_Running均为YES，Seconds_Behind_Master接近0。

MHA高可用组件部署

MHA由Manager和Node组成，Node部署在所有MySQL节点，Manager单独一台。配置文件app.cnf：

[server default]
manager_workdir=/etc/mha
master_ip_failover_script=/usr/local/bin/master_ip_failover
repl_user=repl
repl_password=xxx
ssh_user=root

[server1]
hostname=192.168.1.10
candidate_master=1
[server2]
hostname=192.168.1.11
candidate_master=1
[server3]
hostname=192.168.1.12
no_master=1

用masterha_check_ssh和masterha_check_repl验证SSH互通与复制健康，全部通过后再启动manager进程。

故障切换验证流程

手动停掉主库模拟故障：

masterha_stop --conf=/opt/lib/app.cnf
systemctl stop mysql   # 模拟主库宕机
masterha_master_switch --conf=/opt/lib/app.cnf --master_state=alive

MHA会选出candidate主节点、补齐复制位点、提升新主，并把VIP漂移到新主。验证新主可写、从库与新主重新同步、应用端连接自动切换。切换耗时通常在10秒量级，SLA允许的窗口先确认。

高可用架构的脑裂与一致性防护

主库假死时容易被脑裂：原主恢复后继续写入。解决办法：半同步复制减少主从切换丢数据，MHA切换前强制杀原主进程防止双写，配合VIP和防火墙规则让应用只连到新主。切换完成后把原主降级为从库重新接入，避免两边数据同时变化。