1. MySQL高可用集群环境搭建实战：MHA配置详解
在数据库运维领域，高可用性一直是核心需求之一。最近我在生产环境部署了一套基于MHA（Master High Availability）的MySQL高可用解决方案，经历了从环境准备到故障切换的全过程。本文将详细记录这次实战经验，特别适合需要构建MySQL高可用架构的DBA和运维工程师参考。
MHA是一套成熟的MySQL高可用解决方案，能在主库发生故障时，快速自动地将数据最新的从库提升为新主库，并让其他从库自动指向新主库。相比传统的主从切换方案，MHA的最大优势是能够最大程度保证数据一致性，通常只需10-30秒即可完成故障转移。下面我就从环境准备开始，逐步展示整个配置过程。
2. 环境准备与基础配置
2.1 实验环境规划
我们采用四台服务器搭建测试环境，具体规划如下：
| 设备 | 主机名 | IP地址 | 角色说明 |
|---|---|---|---|
| 主机1 | MYSQL1 | 192.168.220.33 | 初始主库(Master) |
| 主机2 | MYSQL2 | 192.168.220.34 | 从库(Slave)，候选主库 |
| 主机3 | MYSQL3 | 192.168.220.35 | 从库(Slave)，仅作为从库 |
| 主机4 | MHA | 192.168.220.36 | MHA管理节点 |
注意：在实际生产环境中，建议将MHA管理节点部署在独立服务器上，避免与MySQL实例争抢资源。同时，所有节点的时间必须同步，建议配置NTP服务。
2.2 MySQL主从复制配置
在安装MHA之前，需要先建立好MySQL主从复制环境。以下是关键步骤：
- 主库配置（MYSQL1）：
# 编辑my.cnf文件 [mysqld] server-id = 1 log-bin = mysql-bin binlog_format = ROW gtid_mode = ON enforce_gtid_consistency = ON binlog_group_commit_sync_delay = 100 binlog_group_commit_sync_no_delay_count = 10- 从库配置（MYSQL2和MYSQL3）：
[mysqld] server-id = 2 # MYSQL2设为2，MYSQL3设为3 log-bin = mysql-bin binlog_format = ROW gtid_mode = ON enforce_gtid_consistency = ON log_slave_updates = ON read_only = ON- 创建复制账号： 在主库上执行：
CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'repl_password'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';- 配置主从关系： 在每个从库上执行：
CHANGE MASTER TO MASTER_HOST='192.168.220.33', MASTER_USER='repl', MASTER_PASSWORD='repl_password', MASTER_AUTO_POSITION=1; START SLAVE;3. MHA管理节点安装与配置
3.1 安装必要组件
首先在MHA管理节点上安装所需软件包：
# 安装基础依赖 dnf install perl perl-DBD-MySQL perl-CPAN -y # 通过CPAN安装额外Perl模块 cpan install Config::Tiny install Log::Dispatch install Mail::Sender install Parallel::ForkManager exit # 安装MHA管理包 rpm -ivh mha4mysql-manager-0.58-0.el7.centos.noarch.rpm \ mha4mysql-node-0.58-0.el7.centos.noarch.rpm --nodeps经验分享：安装Mail::Sender时，当提示"Specify defaults for Mail::Sender?"选择y，然后编码选择n。其他模块安装直接按回车使用默认选项即可。
3.2 在所有节点安装MHA Node包
需要在所有MySQL节点上安装mha4mysql-node包：
for i in 33 34 35; do scp mha4mysql-node-0.58-0.el7.centos.noarch.rpm root@192.168.220.$i:/root/ ssh root@192.168.220.$i "rpm -ivh /root/mha4mysql-node-0.58-0.el7.centos.noarch.rpm --nodeps" done3.3 修改MHA检测代码
为避免版本检测问题，需要修改NodeUtil.pm文件：
vim /usr/share/perl5/vendor_perl/MHA/NodeUtil.pm # 注释掉以下代码段 # sub parse_mysql_major_version($) { # my $str = shift; # my $result = sprintf( '%03d%03d', $str =~ m/(\d+)/g ); # return $result; # }4. MHA配置文件详解
4.1 创建配置文件模板
mkdir -p /etc/masterha tar zxf mha4mysql-manager-0.58.tar.gz cd mha4mysql-manager-0.58 cat samples/conf/masterha_default.cnf samples/conf/app1.cnf > /etc/masterha/app1.cnf4.2 配置文件关键参数解析
以下是经过优化的配置文件示例：
[server default] user=root password=your_mysql_root_password ssh_user=root repl_user=repl repl_password=repl_password master_binlog_dir=/var/lib/mysql remote_workdir=/tmp secondary_check_script=masterha_secondary_check -s 192.168.220.33 -s 192.168.220.34 ping_interval=3 manager_workdir=/etc/masterha manager_log=/etc/masterha/mha.log [server1] hostname=192.168.220.33 candidate_master=1 check_repl_delay=0 [server2] hostname=192.168.220.34 candidate_master=1 check_repl_delay=0 [server3] hostname=192.168.220.35 no_master=1关键参数说明：
candidate_master=1：标记该节点为候选主库check_repl_delay=0：不检查复制延迟no_master=1：该节点永远不会被提升为主库secondary_check_script：用于多路径检测主库是否真的宕机
5. MHA运行与测试
5.1 检查复制集群状态
masterha_check_repl --conf=/etc/masterha/app1.cnf正常输出应显示所有节点状态正常，类似如下：
Fri Feb 27 16:23:51 2026 - [info] Alive Servers: Fri Feb 27 16:23:51 2026 - [info] 192.168.220.33(192.168.220.33:3306) Fri Feb 27 16:23:51 2026 - [info] 192.168.220.34(192.168.220.34:3306) Fri Feb 27 16:23:51 2026 - [info] 192.168.220.35(192.168.220.35:3306)5.2 主库无故障切换测试
masterha_master_switch \ --conf=/etc/masterha/app1.cnf \ --master_state=alive \ --new_master_host=192.168.220.34 \ --new_master_port=3306 \ --orig_master_is_new_slave \ --running_updates_limit=10000切换过程中会提示确认，输入"yes"继续。切换完成后，可以检查各从库状态确认是否已指向新主库。
5.3 主库故障模拟与自动切换
- 启动MHA监控：
masterha_manager --conf=/etc/masterha/app1.cnf &- 模拟主库故障：
# 在主库上执行 /etc/init.d/mysqld stop- 观察MHA日志：
tail -f /etc/masterha/mha.log正常情况下，MHA会在30秒内完成故障检测和主从切换。
6. 故障恢复与日常维护
6.1 故障恢复流程
当原主库修复后，需要重新加入集群：
- 删除failover标记文件：
rm -f /etc/masterha/app1.failover.complete- 启动原主库MySQL服务：
/etc/init.d/mysqld start- 配置为从库指向新主库：
CHANGE MASTER TO MASTER_HOST='192.168.220.34', MASTER_USER='repl', MASTER_PASSWORD='repl_password', MASTER_AUTO_POSITION=1; START SLAVE;6.2 日常维护建议
- 定期检查：使用
masterha_check_repl定期检查集群状态 - 日志监控：监控MHA日志文件
/etc/masterha/mha.log - 邮件报警：配置
report_script参数实现故障邮件通知 - VIP切换：结合
master_ip_failover_script实现虚拟IP自动漂移
7. 常见问题与解决方案
7.1 SSH连接问题
问题现象：MHA无法通过SSH连接到MySQL节点
解决方案：
- 确保所有节点间配置了SSH免密登录
- 检查
ssh_user参数是否正确 - 测试SSH连接：
ssh root@192.168.220.33 date
7.2 复制延迟导致切换失败
问题现象：切换时因复制延迟被中止
解决方案：
- 设置
check_repl_delay=0临时忽略延迟检查 - 优化MySQL参数减少复制延迟
- 对于确实延迟较大的从库，设置
no_master=1
7.3 切换后应用连接问题
问题现象：切换后应用仍连接旧主库
解决方案：
- 实���读写分离中间件（如ProxySQL）
- 使用DNS别名或虚拟IP
- 配置应用连接字符串自动更新机制
在实际生产环境中部署MHA时，建议先在测试环境充分验证，并制定详细的回滚方案。同时，MHA应与数据库监控系统集成，确保能及时发现和处理故障。
