MHA（Master High Availability）是 MySQL 数据库的一套高可用解决方案，专为解决 MySQL 主从复制架构中的故障自动切换问题而设计。它能在主库发生故障时，快速将从库提升为新主库，最大限度减少数据库宕机时间，保障业务连续性。
一、MHA 的核心组件与角色
MHA 架构由
1 个管理节点（Manager）和多个数据库节点（Node）组成，各角色分工明确：
1. 管理节点 MHA Manager
核心作用：监控主库状态、检测故障、执行自动切换
Failover关键功能：
定时通过 SSH 连接检查所有数据库节点健康状态
主库故障时，选择最优从库提升为新主库
协调其他从库重新指向新主库，重建复制关系
记录切换过程日志，支持邮件 / 脚本通知
2. 数据库节点 MHA Node
包含 1 个主库（Master）和多个从库（Slave），均部署
mha4mysql-node软件包从库：分为两种角色
候选主库（Candidate Master）：配置
candidate_master=1，优先被选为主库普通从库：仅作为数据备份，不参与主库竞选
核心作用：
主库：处理业务读写请求
从库：通过主从复制同步主库数据，提供冗余
运行节点脚本，配合 Manager 完成故障检测与切换
二、MHA 的工作原理
MHA 通过以下流程实现高可用，
核心是 “快速检测故障 + 最小数据丢失切换”：
1. 正常状态：健康监控
Manager 节点每几秒（可配置）通过 SSH 连接主库，执行
show processlist等命令检测存活状态同时监控主从复制延迟，记录各从库的日志位置
Relay_Master_Log_File、Exec_Master_Log_Pos
2. 故障检测：主库异常判断
当满足以下条件时，判定主库故障：
SSH 连接主库失败（网络 / 进程故障）
主库 MySQL 进程无响应（
ping检查失败）主库虽然存活但无法提供服务（如 binlog 损坏）
3. 故障切换Failover：核心流程
主库确认故障后，Manager 执行自动切换，分 6 步完成：
① 保存主库二进制日志 → ② 选择新主库 → ③ 提升新主库 → ④ 其他从库指向新主库 → ⑤ 清理旧主库配置 → ⑥ 通知业务关键步骤详解：
保存二进制日志：尝试通过 SSH 从主库残留的 binlog 文件中抢救未同步数据（减少数据丢失）
选择新主库：优先选
candidate_master=1的从库，其次选数据最新（复制延迟最小）的从库提升新主库：对选中的从库执行
stop slave; reset slave all;，使其成为可写主库重建复制关系：其他从库通过
change master to指向新主库，基于新主库的 binlog 位置开始同步
4. 切换完成：业务恢复
新主库接管读写请求，从库重新开始同步
Manager 发送切换完成通知（邮件 / 脚本），可配合 VIP（虚拟 IP）漂移自动更新业务连接地址
三、MHA 的核心优势
数据丢失极少：
切换时会尝试从主库抢救未同步的 binlog
支持半同步复制（semi-sync），进一步降低数据丢失风险
切换速度快：
从故障检测到完成切换通常在 10-30 秒内
无需重启数据库进程，仅通过 SQL 命令完成角色转换
兼容性好：
支持 MySQL 5.5+、MariaDB 等主流版本
兼容传统主从复制、GTID 复制模式
低侵入性：
不修改 MySQL 内核，通过外部脚本实现高可用
正常运行时不影响主从复制性能
四、MHA 的典型架构部署
1. 基础架构图
[业务服务器]
↓
[VIP: 192.168.1.100] # 虚拟IP，指向当前主库
↓
[MHA Manager] # 管理节点，部署mha4mysql-manager
↙ ↓ ↘
[主库] [从库1] [从库2] # 所有节点部署mha4mysql-node
(Master) (候选主库) (普通从库)2. 核心配置文件（manager.cnf）
[server default]
# 所有节点的SSH用户
ssh_user=mysql
# 复制用户（主从同步使用）
repl_user=repl
repl_password=repl123
# 管理用户（MHA连接数据库使用）
manager_workdir=/var/log/mha/app1
manager_log=/var/log/mha/app1/manager.log
[server1]
hostname=192.168.1.11 # 主库
port=3306
[server2]
hostname=192.168.1.12 # 候选主库
port=3306
candidate_master=1 # 优先作为新主库
[server3]
hostname=192.168.1.13 # 普通从库
port=3306五、MHA 的局限性与解决方案
无自动恢复旧主库功能：
旧主库修复后需手动重新加入集群（作为从库指向新主库）
解决方案：配合脚本自动检测旧主库状态，修复后自动配置为从库
不支持多主架构：
仅适用于一主多从的传统复制架构
解决方案：结合 Proxy（如 MyCat）实现读写分离与多主路由
依赖 SSH 免密登录：
Manager 需免密登录所有节点，存在一定安全风险
解决方案：限制 SSH 用户权限，仅开放必要命令执行权限
六、MHA 与其他高可用方案对比
| 方案 | 切换速度 | 数据一致性 | 复杂度 | 适用场景 |
|---|---|---|---|---|
| MHA | 10-30 秒 | 高（极少丢失） | 中 | 中小规模 MySQL 集群 |
| 主从 + Keepalived | 秒级 | 低（可能丢失） | 低 | 对数据一致性要求不高场景 |
| MySQL Group Replication | 秒级 | 高（强一致） | 高 | 大规模分布式集群 |
总结
MHA 是 MySQL 主从架构下的成熟高可用方案，通过 “管理节点 + 数据库节点” 的架构，以低复杂度、高可靠性实现故障自动切换，特别适合对数据一致性要求较高、需要快速恢复的业务场景。实际部署时，建议结合半同步复制、VIP 漂移、监控告警等功能，构建更完善的高可用体系。
实战
1、MHA基础实战
| 机器名称 | IP配置 | 操作系统版本/数据库版本 | 说明 |
|---|---|---|---|
| mha | 192.168.210.155 | rhel7.9 | manager控制器 |
| master | 192.168.210.146 | rhel7.9/mysql8.0.40 | 数据库主服务器 |
| rep1 | 192.168.210.149 | rhel7.9/mysql8.0.40 | 数据库从服务器 |
| rep2 | 192.168.210.150 | rhel7.9/mysql8.0.40 | 数据库从服务器 |
初始化主节点master的配置：
初始化rep1和rep2节点：与上相同
三台机子同时开启mysql
master机子开创账户
rep1:
rep2:
在master上查看是否已经配置完毕（主从同步）ok!
在四台机子上分别配置域名解析：
上传MHA压缩包并解压
给另外三个机子分发：（我已经配置好互相免密）【第一次会需要密码】
分别配免密：
在master进行mha账号创建：
写MHA配置文件：
检查成功！
2、VIP配置
配置VIP文件：
添加内容
master_ip_failover_script=/usr/local/bin/master_ip_failover
在主库上手动配置第一次的VIP地址：
在mha-manager上启动MHA
masterha_manager --conf=/etc/mha/app1.cnf --ignore_last_failover在master节点关闭mysql服务模拟主节点数据崩溃：
在rep1上查看VIP，自动切换成功！
若要看故障解决及遇到各种问题解决方案请期待下次博客！！！