脚本部署MHA集群
最近在帮一个朋友梳理MySQL高可用方案，他那边业务量不大，但对数据可靠性要求挺高，主库宕机超过五分钟就要被领导约谈那种。调研了一圈，最后还是选了MHA（Master High Availability）这套方案。不少人在这一步直接卡住，觉得MHA配置繁琐、节点多、手工操作容易漏。其实只要把部署过程脚本化，半小时建一套集群完全不是问题。这篇文章就把我整理的一键部署脚本思路、核心配置和踩过的坑全部盘一遍，给正在折腾MySQL高可用的同学一个可以抄作业的参考。
先明确一下MHA的核心价值：它是一套成熟的MySQL主从架构自动故障切换方案，在主库发生故障时，能自动从多个从库中选出数据最完整的一个，补全差异日志，提升为新主库，同时让其余从库重新指向新主库，整个切换过程对业务方透明，应用只需要感知VIP漂移或连接串切换。相比MGR、Orchestrator这些方案，MHA的优势在于对已有主从架构改动极小，不需要改表结构、不需要插件支持，非常适合基于异步复制搭建的高可用环境。
1. 内容整体设计与思路拆解
1.1 为什么选择脚本化部署MHA
手工部署MHA，要经历的过程大致是这样：在所有节点安装依赖包、安装node包、管理节点安装manager包、配置SSH互信、写app1.cn配置文件、编写VIP切换脚本、启动manager进程、验证切换流程。每一步都依赖上一步成功，而且中间穿插大量容易出错的环节，比如Perl模块缺失、SSH权限不对、配置文件路径写错。多节点环境下，这种手工操作很容易出现"这台上一步忘了装"之类的低级问题。
脚本化改造之后，整个流程被固化成标准化步骤，重复执行稳定可靠，机器多了也不会漏环节。另外一个实际业务场景是，现在很多公司数据库节点是批量交付的，初始化一批新环境时，脚本跑一遍和一上午手工敲命令的效率差距不是一星半点。脚本还能保证所有环境配置一致，减少"开发环境和生产环境配置漂移"导致的诡异问题。
1.2 MHA故障切换机制与脚本逻辑的对应关系
在写脚本之前，得先把MHA的工作机制吃透。MHA Manager进程通过周期性探测主库的MySQL连通性来判断主库是否宕机，默认ping间隔是3秒，连续多次ping失败就触发切换流程。
触发切换后，MHA会做这几件事：
- 确认主库不可用，锁定集群进入切换状态。
- 从所有从库中筛选数据最新的节点，这个过程会对比各从库的relay log（中继日志）差异。
- 对候选主库应用缺失的日志，使其数据追上原主库最后的写入位置。
- 将候选主库提升为新的主库，清理read_only标记。
- 让其他从库重新change master到新主库。
- 如果配置了VIP漂移脚本，则执行VIP切换到新主库。
脚本部署给出的动作序列，需要严格对齐这套机制：环境准备对应安装和依赖，SSH互信对应MHA各节点之间通信的基础，配置对应选主和切换参数，VIP脚本对应最后一步的网络切换。想清楚这个对应关系，写脚本时就知道每一步是为了支撑哪个环节，不会盲目照搬。
1.3 脚本化方案的适用边界
一个要提前说清楚的点：MHA解决的是主库宕机后的故障切换，它不等于数据零丢失方案。在异步复制下，如果主库突然断电，极少数最近提交的事务还没来得及同步到从库，切换后这部分数据会丢。如果业务对数据零丢失有强需求，需要开半同步复制（semi-sync replication）配合，或者在应用层做双写补偿。我这边给出的脚本默认基于异步复制，但会预留半同步的配置开关，因为生产环境我遇到过因为半同步超时导致可用性下降的案例，这个后面细说。
另外，MHA不适合跨地域的大延迟场景。如果主从机房距离超过几十毫秒RTT，MHA的日志补偿过程会非常耗时，切换RTO（Recovery Time Objective）会拉长。脚本部署面向的是同机房或者同城双机房的低延迟内网场景。
2. 部署环境准备与主机规划
2.1 节点角色与推荐规格
一个最小可用环境至少需要三台机器：一台主库、一台从库、一台独立的管理节点（也可以复用从库部署Manager，但生产环境建议独立，避免切换时管理进程所在的从库被提升导致服务重叠）。下面是我建议的规划表：
| 角色 | MySQL实例 | MHA组件 | 推荐配置 | 备注 |
|---|---|---|---|---|
| 主库节点 | 读写实例 | mha4mysql-node | 4C8G，SSD | 业务主写入节点 |
| 从库节点1 | 只读实例 | mha4mysql-node | 4C8G，SSD | 切换时的候选主库 |
| 从库节点2 | 只读实例 | mha4mysql-node | 4C8G，HDD | 只读扩展节点 |
| 管理节点 | 不部署 | mha4mysql-node + manager | 2C4G | 故障切换控制点 |
版本搭配上，MySQL使用5.7版本（PERCONA分支或者官方社区版均可），MHA使用目前社区仍在维护的分支。原版MHA从2018年后基本停止更新，社区fork版本修复了很多Perl兼容性问题，强烈建议不要用老掉牙的0.56原版往新系统上装，编译安装时你会被各种依赖折磨到怀疑人生。
2.2 MySQL主从复制前置状态检查
脚本跑起来之前，手工确认几个前置条件，避免脚本执行到一半才发现基础环境有问题：
- 主库binlog已经开启，且格式为ROW，binlog_row_image=FULL。
- 各从库server_id唯一，主从复制已正常工作，Seconds_Behind_Master为0。
- MySQL有专门用于MHA的账号，权限为对所有库的SELECT、SUPER、REPLICATION SLAVE、REPLICATION CLIENT。
- 各节点之间防火墙放行MHA需要的端口（MySQL 3306和Manager通信端口，默认22用于SSH）。
- /etc/hosts里所有节点主机名和IP映射一致，这个很少有人注意但极其重要，MHA内部按主机名通信，解析不一致直接报错。
提示：建议在所有节点上统一使用内网主机名，而不是IP来做MHA配置里的标识。后续切换日志里，主机名比IP更容易定位问题节点。
2.3 依赖包准备
各节点都需要安装Perl相关模块，CentOS 7系列的机器需要开启epel源，否则部分CPAN模块拉不下来。核心依赖包括DBD::mysql、Config::Tiny、Log::Dispatch、File::Basename、Parallel::ForkManager等。这些模块看着不起眼，缺一个都可能导致manager起不来或者切换脚本半路报错。
脚本里我会分步执行，第一步就是安装这些依赖。如果你在一个离线内网环境，提前打包Perl模块的RPM或用CPAN镜像源会很省心。别问我为什么强调这个，我曾经在一个金融客户的内网环境装MHA，因为外网隔离，光解决Perl模块依赖就折腾了两个多小时。
3. 核心脚本实现与关键函数拆解
3.1 脚本整体框架
我习惯把部署脚本拆成三级结构：主入口脚本、配置模板、功能函数库。这样一个跑批脚本可以多次重复执行，还方便维护。主入口负责读取配置文件里的节点信息和部署模式，然后按顺序调用函数库里的安装、配置、启动函数。
#!/bin/bash # deploy_mha.sh - MHA集群一键部署脚本 set -o errexit set -o nounset set -o pipefail # 加载配置文件 source ./mha_cluster.conf LOG_FILE="${LOG_PATH}/deploy_$(date +%Y%m%d_%H%M%S).log" exec > >(tee -a "${LOG_FILE}") 2>&1 # 基础检查 function check_precondition() { echo ">>> [1/7] 检查基础环境" # 检查各节点SSH连通性 for host in "${ALL_NODES[@]}"; do ssh -o ConnectTimeout=5 -o StrictHostKeyChecking=no "${host}" 'echo ok' done # 检查MySQL连通性 for port in "${MYSQL_PORT[@]}"; do mysqladmin -h "${host}" -P "${port}" ping done }这个函数的设计逻辑是"快速失败"，如果前置检查发现某个节点SSH不上，直接终止后续步骤，节省排查时间。
3.2 SSH互信配置函数
MHA Manager需要在所有节点之间执行SSH操作，比如在从库上拉取relay log差异、在候选主库上应用日志、在其余从库上执行change master命令，这些动作默认走SSH通道。没有互信的话，切换过程中会频繁要求输密码，实际上做不到自动化。
function setup_ssh_trust() { echo ">>> [2/7] 配置SSH互信" if [ ! -f ~/.ssh/id_rsa ]; then ssh-keygen -t rsa -b 2048 -N "" -f ~/.ssh/id_rsa fi for host in "${ALL_NODES[@]}"; do ssh-copy-id -i ~/.ssh/id_rsa.pub "${SSH_USER}@${host}" done }细节提醒：部署脚本里我固定使用deployer这个专用系统账号来做SSH互信和MHA管理，不建议直接用root。ssh-copy-id第一次连接可能需要输密码，这种半自动化交互用expect或者sshpass包处理即可，脚本里我会写一个带expect的变体，纯交互会让批处理跑不下去。
3.3 MHA依赖安装函数
MHA的perl模块安装是坑最多的环节，特别是DBD::mysql编译时需要mysql客户端库。很多人在这个步骤报错，提示找不到mysql_config，就是因为系统里没有安装mysql-devel包。
function install_dependencies() { echo ">>> [3/7] 安装MHA依赖" yum install -y perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes perl-ExtUtils-MakeMaker # 如果Perl模块版本过旧，从cpan源补装 cpan install DBD::mysql }值得注意的是，部分系统预装的老版本DBD::mysql只支持老的MySQL认证协议，连接MySQL 8.0或5.7的caching_sha2_password账号时会报认证失败。务必升级DBD::mysql到4.050以上版本，且编译时指定mysql_config路径，确保模块链接到正确的客户端库。
3.4 MHA安装包构建与分发
MHA分两个包：node包需要在所有MySQL节点安装，manager包只在管理节点安装。node包的安装本质上只是放一些Perl脚本到系统目录里，不需要编译；manager包同样也是Perl脚本为主。
function install_mha() { echo ">>> [4/7] 安装MHA node/manager包" if [ ! -d "${PACKAGE_DIR}/mha4mysql-node" ]; then git clone -b master "${MHA_REPO_NODE}" "${PACKAGE_DIR}/mha4mysql-node" fi cd "${PACKAGE_DIR}/mha4mysql-node" perl Makefile.PL make && make install # 仅在管理节点执行 if [ "${HOSTNAME}" == "${MANAGER_HOST}" ]; then cd "${PACKAGE_DIR}/mha4mysql-manager" perl Makefile.PL make && make install fi }这个函数里，我用git clone的方式拉取社区维护版代码，而不是下载老旧的release tarball。社区维护版修复了在新版本Perl下编译失败和部分脚本不兼容的问题。脚本也兼容本地已有软件包的情况，用户可以把rpm或tar包放到指定目录，脚本检测到就跳过clone。
4. MHA核心配置解析与VIP切换脚本
4.1 app1.cn配置文件详解
MHA切换的核心配置是一个类似下面这样的自定义配置文件，管理节点启动时通过--conf参数指定路径。这个文件内容直接决定了选主策略、日志应用方式和切换行为，必须理解每个字段的含义。
[server default] manager_workdir=/var/log/masterha/app1 manager_log=/var/log/masterha/app1/manager.log master_binlog_dir=/data/mysql/logs password=your_password ping_interval=3 remote_workdir=/var/log/masterha/app1 repl_user=repl repl_password=repl_password secondary_check_script=/usr/local/bin/masterha_secondary_check -s <ip1> -s <ip2> shutdown_script="" ssh_user=deployer [server1] hostname=db1 candidate_master=1 [server2] hostname=db2 candidate_master=1 check_repl_delay=0 [server3] hostname=db3 no_master=1关键字段拆解：
ping_interval：主库健康检查间隔，默认3秒，如果主库负载很高，建议加大到5-10秒，否则主库瞬时抖动会频繁触发误切换。candidate_master：标记该从库有资格被提升为新主库，通常性能较好的从库才设置。check_repl_delay=0：让MHA在选主时忽略从库复制延迟的检查。这个参数要慎用，如果延迟特别大，切换后会有明显数据缺口。我一般建议生产环境保持默认1，只有在从库性能特别好的情况下才关闭检查。no_master=1：强制该节点不能被提升为主库，比如纯灾备节点或者低配从库。secondary_check_script：第二路健康检查，通过另一台机器去探测主库状态，避免网络分区导致误判。这是一个非常重要的优化项，不加它，单点网络抖动就可能引发一次完整切换。
4.2 VIP切换脚本编写要点
MHA的核心切换动作是数据库层面的，但业务访问MySQL通常通过VIP或域名。VIP漂移脚本的好坏直接决定了切换RTO。一个典型的master_ip_failover脚本，挂在master_ip_failover_script参数上，执行逻辑如下：
#!/usr/bin/env perl use strict; use warnings FATAL => 'all'; my $vip = '192.168.56.200'; my $ssh_start_vip = "/sbin/ip addr add $vip/24 dev eth0 label eth0:0"; my $ssh_stop_vip = "/sbin/ip addr del $vip/24 dev eth0 label eth0:0"; # 在旧主库上删除VIP my $exit_code = 0; # 从参数中获取old_ip和new_ip # 在当前新主库上绑定VIP system("ssh $new_host \"$ssh_start_vip\"");注意几个实操点：
- 脚本必须在管理节点上能免密执行，因为故障切换时是manager进程通过SSH驱动远程主机执行VIP绑定。
- VIP漂移除了绑IP，还需要考虑ARP广播问题。有些网络环境下，VIP漂移后业务端ARP缓存不更新，导致连接仍然发往旧主库。解决办法是执行
arping -U -I eth0 -c 3 <vip>广播一下，脚本里要把这个动作加进去。 - 如果数据库架构接入了LVS或SLB，VIP漂移脚本就不是绑IP，而是调用负载均衡接口摘除旧节点、挂载新节点。这种情况下，接口调用失败要在脚本里重试三次以上，避免切换成功但流量没切过去。
4.3 健康检查脚本配置
MHA默认的健康检查是从管理节点直连主库的3306端口，这种方式在管理节点和主库之间网络中断时会有误判风险。更好的做法是配置多个检查点。
我这里的部署脚本生成一个secondary_check脚本，从两个不同的从库节点分别去ping主库，只有两个从库都连不上主库才判定主库真的挂了。这个设计在真实切换中非常实用，实测下来能过滤掉90%以上的网络抖动误触发。
5. 实操验证与常见问题排查实录
5.1 部署完成后的集群状态自检
脚本全部跑完之后，不要急着上线，先做一次全面的状态自检：
- 在管理节点执行
masterha_check_ssh --conf=/etc/masterha/app1.cn，检查SSH互信是否OK。 - 执行
masterha_check_repl --conf=/etc/masterha/app1.cn，检查复制链路是否健康。 - 启动manager：
masterha_manager --conf=/etc/masterha/app1.cn --daemon --remove_dead_master_conf --ignore_last_failover。 - 观察manager.log，确认监控进程正常启动，没有报连接或认证错误。
这一步经常出现的问题是check_repl阶段报Binlog is not empty on db1或者Relative log position >，多半是主库的binlog没有被正确清理，或者某个从库的relay log存在异常。逐个节点执行show slave status\G查看Exec_Master_Log_Pos，确认三个节点的位点一致。
5.2 主库宕机切换实测
部署脚本交付后，我建议至少做一次完整的故障切换演练，这比任何配置检查都更能暴露问题。演练方法很直接：手工停掉主库MySQL进程，观察MHA是否自动完成切换。
推荐用下面的命令监控切换过程：
while true; do mysql -h 192.168.56.200 -u mha_user -p*** -e "select @@hostname, now()" 2>/dev/null sleep 1 done这个循环每一秒通过VIP连接一次，输出当前真实的主机名。切换发生时你能直接看到hostname从db1跳到了db2。我在实测环境里，停掉主库后大约10秒完成切换，VIP漂移后业务恢复。切换日志的顺序大致是：
- 连续ping失败，判定主库不可用。
- 获取所有从库的relay log，进行差异对比。
- 将db2的relay log补齐到最新位点。
- 在db2上执行
stop slave; reset slave all;，清除只读，提升为主库。 - 在db3上执行新的change master，指向db2。
- 执行master_ip_failover脚本，VIP漂移到db2。
5.3 老大难的relay log不完整问题
切换过程中最常碰到的一个报错是relay log is incomplete，根源在于部分从库的relay log没同步完全，MHA在尝试补齐时发现日志有空洞。排查思路如下：
- 检查该从库的
relay_log_recovery参数，建议打开，这样MySQL重启时会自动丢弃不完整的relay log并重新拉取。 - MHA版本过旧时，对relay log的解析经常出问题，换到社区维护版分支后问题大幅减少。
- 从库磁盘满了导致relay log写不进去，也是常见诱因，检查
show slave status里的Last_IO_Error和磁盘使用率。
5.4 Manager进程意外退出的复盘
还有一个典型生产事故，manager进程以daemon方式跑着，某天后端同学反馈切换没生效，查看日志发现manager早在两天前就退出了，原因是--ignore_last_failover参数没加。这个参数表示忽略上一次切换记录，不加的话，MHA会在一次切换后自动退出，防止短时间内重复切换。但如果manager因为异常退出，重启时发现last_failover记录存在，会直接拒绝启动。
解决办法是在启动命令里显式加上--ignore_last_failover，同时用systemd服务守护manager进程，进程退出后自动拉起。脚本里我会生成对应的systemd unit文件：
[Unit] Description=MHA Manager for app1 After=network.target [Service] Type=forking ExecStart=/usr/local/bin/masterha_manager --conf=/etc/masterha/app1.cn --daemon --ignore_last_failover ExecStop=/usr/local/bin/masterha_stop --conf=/etc/masterha/app1.cn Restart=always RestartSec=10 [Install] WantedBy=multi-user.target注意Type=forking要和--daemon配合使用，systemd会handle住masterha_manager自己fork出的子进程。Restart=always保证异常退出后10秒自动拉起，这样即使manager进程崩溃也不会留下"无人值守"的空窗期。
5.5 部署脚本的幂等性设计
运维工具最忌讳"跑一半报错，修复后从头再来"的情况。整个部署脚本我在设计时坚持幂等原则，每个函数执行前先判断目标状态：
- 安装依赖前检查rpm是否已存在。
- SSH互信前检查是否已经能免密登录。
- 配置文件写入前备份原文件。
- service启动前检查进程是否已经在运行。
这样脚本可以在任意步骤失败后修复问题再跑，不用担心重复执行导致配置错乱。对带状态的数据库节点，脚本还专门做了保护：如果检测到某个节点已经是主库角色，不会误执行从库初始化操作。
6. 部署后的调优与扩展经验
6.1 切换RTO的优化空间
默认配置下，一次主库宕机到业务恢复的RTO大概在10-20秒之间，主要时间花在relay log对比和日志应用上。如果希望进一步压缩：
- 把
ping_interval调低到1秒，但要注意误判风险会增加，配合secondary_check使用才安全。 - 预选候选主库，并保证候选主库和主库的数据延迟尽量低。比如在从库上设置
sync_binlog=1和innodb_flush_log_at_trx_commit=1，牺牲一点从库写入性能换取切换时的日志差距更小。 - 启用并行复制（MTS），从库在追赶relay log时速度更快，切换时日志补偿耗时明显缩短。我实测过开启并行复制后，相同压力下日志追平速度提升3-5倍。
6.2 半同步复制与MHA配合的权衡
异步复制下，MHA存在很小的数据丢失窗口。我前面提到半同步复制，这里展开说一下。打开半同步后，主库提交事务时至少要等一个从库ACK，这个过程中如果从库长时间不响应，主库会退化为异步模式。脚本里我封装了一个setup_semisync函数，自动在master和candidate slave上安装插件并设置超时时间。
生产经验是，半同步的rpl_semi_sync_master_timeout不要设太大，我习惯设到3000毫秒以内，超过就自动降级为异步。否则从库出现性能抖动时，主库的写事务会一直阻塞等待ACK，整个业务写入链路被拖垮，这就本末倒置了。
6.3 扩展：从MHA平滑演进到其他高可用方案
装配了脚本化部署之后，你会发现整个高可用体系的核心是"资源编排"能力。这套脚本稍加改造，就能扩展支持其他高可用组件的部署。比如我后来把类似的脚本结构迁移到了服务发现和配置管理上，把节点列表放到配置中心，实现动态扩容。
MHA虽然是老牌方案，但它的设计思想很值得借鉴：分层监控、多级检查、日志补偿、自动切换、可编排。理解这套思想后，无论以后用Orchestrator，还是基于Raft的MGR，你都能快速上手。脚本部署的价值不只在当下把MHA装好，更在于它逼着你去梳理整个系统的依赖关系、故障转移路径和恢复SOP。
最后再分享一个小技巧：部署脚本跑完后，建议把生成的配置文件和日志目录做一次归档，标注好版本号和部署日期。后续排障或者做配置审计时，翻这些归档比翻聊天记录靠谱得多。生产环境里，文档和脚本本身就是高可用的一部分，这句话一点都不夸张。
