一、MHA 架构概述：为什么需要 MHA？
MySQL 复制（Replication）是实现数据库高可用的常用手段，但当主库（Master）发生故障时，传统的手动切换流程复杂且存在数据丢失风险。MHA（Master High Availability）应运而生，它是一个专门用于 MySQL 高可用性（HA）的软件，能在主库宕机后，自动检测故障，并将其中一个备库（Slave）提升为新主库，同时最大程度地保证数据一致性。
MHA 的核心价值在于其自动化和高效性。它通过监控集群状态，快速完成故障检测、新主库选举、数据补偿（应用差异 Relay Log）和 VIP（虚拟 IP）切换（可选）等操作，将故障恢复时间（RTO）降至分钟级，有效保障了业务连续性。
上图清晰地展示了 MHA 的工作流程，从持续监控到最终完成应用切换，整个过程自动化执行，无需人工干预。
二、环境准备与规划：搭建前的准备工作
在开始搭建 MHA 之前，我们需要明确实验环境。本文以四台 CentOS 7 服务器为例，分别扮演不同角色。
| 服务器 IP | 主机名 | 角色 | 操作系统 |
|---|---|---|---|
| 192.168.1.10 | node1 | Master | CentOS 7 |
| 192.168.1.11 | node2 | Slave 1 | CentOS 7 |
| 192.168.1.12 | node3 | Slave 2 | CentOS 7 |
| 192.168.1.20 | node4 | MHA Manager | CentOS 7 |
所有服务器需关闭防火墙和 SELinux，并确保时间同步（推荐使用 NTP）。此外，各节点间需实现 SSH 互信，以便 MHA Manager 能无密码登录到所有 MySQL 节点执行命令。
此 ER 图展示了 MHA Manager 与 Master、Slave 节点之间的管理关系，以及 Master 与 Slave 之间的复制关系，是 MHA 架构的基础。
三、Master 节点配置：基础环境搭建
首先，我们在 Master 节点（node1）上安装并配置 MySQL。
- 安装 MySQL 5.7（或更高版本）。
- 编辑 MySQL 配置文件
/etc/my.cnf，确保以下关键参数设置正确：
```ini
[mysqld]
server-id=1
log-bin=mysql-bin
binlog_format=ROW
innodb_file_per_table=1
```
- 重启 MySQL 服务。
- 登录 MySQL，创建用于 MHA 管理和复制的用户，并授予相应权限：
```sql
CREATE USER 'mha_user'@'%' IDENTIFIED BY 'mha_password';
GRANT ALL PRIVILEGES ON . TO 'mha_user'@'%';
CREATE USER 'repl'@'%' IDENTIFIED BY 'repl_password';
GRANT REPLICATION SLAVE ON . TO 'repl'@'%';
FLUSH PRIVILEGES;
```
此序列图描绘了在 Master 节点上完成基础配置的步骤，确保 MHA Manager 和 Slave 能够正常连接和操作。
四、Slave 节点配置：构建复制集群
接下来，在 Slave 1（node2）和 Slave 2（node3）上配置 MySQL，并建立与 Master 的主从复制关系。
- 在 node2 和 node3 上安装 MySQL 5.7。
- 编辑
/etc/my.cnf，设置不同的server-id（如 2 和 3），并确保log-bin和binlog_format与 Master 一致。 - 在 Master 节点上锁表并导出数据（或使用 XtraBackup 进行热备）：
```bash
mysql> FLUSH TABLES WITH READ LOCK;
mysqldump -uroot -p --all-databases --master-data=2 --single-transaction > /tmp/all_db.sql
mysql> UNLOCK TABLES;
```
- 将导出的数据文件传输到 Slave 节点并导入。
- 在 Slave 节点上执行
CHANGE MASTER TO命令，配置主从复制：
```sql
CHANGE MASTER TO
MASTER_HOST='192.168.1.10',
MASTER_USER='repl',
MASTER_PASSWORD='repl_password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154;
```
- 启动 Slave 复制并检查状态：
```sql
START SLAVE;
SHOW SLAVE STATUS\G;
```
确保 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes。
此流程图展示了 Slave 节点的配置流程，通过循环检查确保复制关系正确建立。
五、MHA Manager 安装与配置：自动化核心
MHA Manager 是整个高可用方案的控制中心，负责监控、故障检测和切换。
- 在 MHA Manager 节点（node4）上安装 Perl 和必要模块：
```bash
yum install -y perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager
```
- 下载并安装 MHA 软件包（例如 mha4mysql-manager-0.58 和 mha4mysql-node-0.58）。
- 在所有 MySQL 节点上安装 MHA Node 组件。
- 在 Manager 节点上创建 MHA 专属用户，并配置 SSH 互信。
- 创建 MHA 配置文件
/etc/mha/app.cnf，内容如下：
```ini
[server default]
manager_log=/var/log/mha_manager.log
manager_workdir=/var/log/mha_manager
master_binlog_dir=/var/lib/mysql
password=mha_password
user=mha_user
ssh_user=root
repl_password=repl_password
[server1]
hostname=192.168.1.10
candidate_master=1
[server2]
hostname=192.168.1.11
[server3]
hostname=192.168.1.12
```
该类图展示了 MHA Manager、MHA App 和 MHA Node 之间的核心关系，MHA Manager 通过 MHA App 管理多个 MHA Node，实现集群的统一监控与控制。
六、故障切换演练：见证 MHA 的威力
配置完成后，我们可以进行一次故障切换演练，模拟 Master 节点宕机。
- 在 Manager 节点上，使用
masterha_check_ssh和masterha_check_repl检查 SSH 互信和复制状态。 - 模拟 Master 故障：在 node1 上执行
systemctl stop mysql。 - 在 Manager 节点上执行切换命令：
```bash
masterha_master_switch --conf=/etc/mha/app.cnf --master_state=offline --new_master_host=192.168.1.11
```
- 查看切换日志
/var/log/mha_manager/app.log，确认切换过程。 - 验证新 Master（node2）的状态：
```sql
SHOW MASTER STATUS;
```
- 验证旧 Slave（node3）是否已指向新 Master：
```sql
SHOW SLAVE STATUS\G;
```
此状态图直观地展示了故障切换前后的状态变化，从 Master 正常运行到故障发生，再到 MHA 自动切换并恢复服务。
七、总结与优化：让高可用更稳定
MHA 是一个成熟且高效的 MySQL 高可用解决方案，尤其适合对数据一致性要求较高的场景。它通过自动化的故障切换，显著降低了运维复杂度和业务中断时间。
然而，MHA Manager 本身是一个单点，如果 Manager 节点故障，将无法执行切换。为了消除这一单点，可以采用以下方案：
- 部署多个 Manager 节点：配置多个 Manager，通过脚本或监控工具确保至少有一个 Manager 在线。
- 结合 VIP（虚拟 IP）：使用 Keepalived 或类似工具，将 VIP 绑定到当前 Master，切换时同时更新 VIP，实现应用的无感切换。
此饼图展示了 MHA 架构中各组件的职责权重，其中 Slave 节点承担了主要的备份和故障切换任务，是高可用体系的关键组成部分。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/qq_41840843/article/details/167917841
