MySQL高可用方案怎么选：主从复制到MHA部署实操

MySQL 高可用方案的核心目标很简单：当主库宕机时，业务能自动切换到从库继续读写，尽量减少停机时间。
对于零基础用户，最常见也最容易落地的路径是先搭好 MySQL 主从复制，再用 MHA 做故障切换管理。
下面按准备、操作、避坑、验证的顺序讲清楚。

先判断你的业务适合哪种高可用

MySQL 高可用方案不是越复杂越好，先看业务能接受多长的停机时间和多少数据丢失。

• 单机加定时备份：成本最低，但主库故障时恢复时间长，适合个人测试或非核心业务。
• 主从复制加手动切换：能保留一份实时副本，切换需要人工介入，适合中小型业务。
• 主从复制加 MHA：能自动检测主库故障并完成切换，适合对可用性有明确要求的业务。
• MySQL Group Replication 或 InnoDB Cluster：官方方案，部署和维护要求更高，适合有专职 DBA 的团队。

如果你刚开始接触 MySQL 高可用方案，建议从主从复制加 MHA 入手，因为它的原理透明、排错路径清晰。

部署前的环境准备

以下步骤以常见的 Linux 服务器为例，MySQL 版本请以你实际安装的版本为准，命令中的路径和 IP 需要替换成你的真实环境。

至少准备三台机器：一台主库、一台或多台从库、一台 MHA Manager 管理节点。
管理节点可以和数据节点分开，也可以复用其中一台。

每台机器需要确认以下条件：

• MySQL 已安装并可正常启动，主从节点之间网络互通。
• 所有节点时间同步，建议启用 NTP 或 chrony。
• 主从节点的 MySQL 配置中 server-id 必须唯一。
• 主库开启 binlog，从库开启 relay log。

在主库配置文件 my.cnf 中加入或确认以下内容：

[mysqld]
server-id=1
log-bin=mysql-bin
binlog-format=ROW
gtid_mode=ON
enforce_gtid_consistency=ON

从库的 server-id 分别改成 2、3 等不重复的值，其他 binlog 相关配置保持一致。
修改后重启 MySQL 使配置生效。

搭建主从复制

主库上创建用于复制的账号：

CREATE USER 'repl'@'%' IDENTIFIED BY '你的密码';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;

如果使用 GTID 模式，从库执行：

CHANGE MASTER TO
  MASTER_HOST='主库IP',
  MASTER_USER='repl',
  MASTER_PASSWORD='你的密码',
  MASTER_AUTO_POSITION=1;
START SLAVE;

然后在从库运行 SHOW SLAVE STATUS\G，确认 Slave_IO_Running 和 Slave_SQL_Running 都是 Yes。
如果其中一项是 No，先看 Last_IO_Error 或 Last_SQL_Error 的提示，常见原因是账号权限、网络不通或主从数据不一致。

主从复制正常后，MySQL 高可用方案就有了数据基础，随后才能谈自动切换。

用 MHA 实现故障自动切换

MHA 由 Manager 和 Node 两部分组成，Node 装在所有 MySQL 节点上，Manager 装在管理节点上。
安装方式因系统而异，建议参考你所用发行版的软件源或 MHA 官方仓库。

基本流程如下：

• 在所有 MySQL 节点安装 MHA Node。
• 在管理节点安装 MHA Manager。
• 配置 SSH 免密登录，让 Manager 能免密连接到所有数据节点。
• 创建 MHA 管理用户，并授予管理权限。
• 编写 MHA 配置文件，通常放在 /etc/masterha/app1.cnf，写明主从节点 IP、复制账号、管理账号和切换脚本路径。
• 运行 masterha_check_ssh 和 masterha_check_repl 检查环境。
• 检查通过后启动 Manager：masterha_manager --conf=/etc/masterha/app1.cnf。

MHA 切换时会提升一个从库为新主库，并让其他从库指向新主库。
切换完成后，原主库不会自动重新加入集群，需要人工修复后手动配置。

避坑与常见问题

主从复制延迟过大：先看 SHOW SLAVE STATUS\G 中的 Seconds_Behind_Master，如果持续增长，检查从库磁盘 IO、大事务和慢 SQL。

MHA 切换失败：多数情况是 SSH 免密没配好、复制账号权限不足或 VIP 切换脚本路径错误。
先用 masterha_check_ssh 和 masterha_check_repl 逐项排查。

切换后数据不一致：MHA 默认会尽量补齐差异，但无法保证零丢失。
如果业务不能接受任何数据丢失，需要评估半同步复制或组复制方案。

不要只搭不管：高可用方案需要定期演练切换，否则真正故障时才发现脚本或权限有问题。

如何验证方案是否生效

• 在从库执行 SHOW SLAVE STATUS\G，确认两个线程为 Yes。
• 在主库写入一条测试数据，到从库查询确认已同步。
• 模拟主库宕机，观察 MHA 是否自动提升从库，并检查业务连接是否切到新主库。
• 切换完成后，检查新主库的 read_only 状态和复制关系是否正确。

MySQL 高可用方案的落地重点不是装了多少组件，而是复制链路稳定、切换脚本可靠、故障后能快速验证。
先把主从复制做扎实，再上 MHA，遇到问题按报错信息逐项排查，比盲目换方案更有效。