MHA高可用集群部署：避开那些“坑”，让切换真正可靠
MHA高可用集群必须在所有MySQL节点安装mha4mysql-node，否则故障切换失败；Manager仅发指令，Node执行CHANGE MASTER TO等操作并提供关键脚本；SSH需root免密且禁用requiretty；配置文件缺user、repl_user、ssh_user等任一字段均导致校验失败。
部署MHA集群，千万别以为装上Manager就万事大吉。Node组件必须在每一个MySQL实例上安装并验证通过，这是故障切换能够成功执行的绝对前提，否则切换流程会在关键时刻掉链子。
为什么每个MySQL节点都必须安装 mha4mysql-node？
这里有个关键的角色分工需要厘清：Manager节点更像是一个“指挥官”，它负责监控和下达指令，但具体的数据同步和主从切换动作，比如执行 CHANGE MASTER TO、START SLA VE、RESET SLA VE 这些命令，都是由各个节点本地的 mha4mysql-node 来完成的。如果某个从库节点漏装了Node，Manager在切换时就会卡在“Waiting for sla ves to apply relay logs”这一步，或者直接报错 Can't exec "apply_diff_relay_logs"，导致切换失败。
- Node组件提供了
apply_diff_relay_logs、filter_mysqlbinlog等核心脚本，专门用来补全主库宕机前未来得及同步的binlog数据，这是保证数据一致性的关键。 - Manager通过SSH远程调用节点上的
masterha_check_repl等命令，而这些命令的执行依赖于本地Node的安装路径（默认是/usr/bin/）。 - 一个常见的依赖陷阱：在CentOS 7这类系统上，默认的Perl版本可能较低，而
mha4mysql-node-0.58需要perl-DBD-MySQL模块。如果没提前装好，使用rpm -ivh安装时可能会因为依赖缺失而静默退出，看似装了，实则无效。
mha4mysql-manager 安装后，别忘了这些手动步骤
Manager的RPM安装包可不会帮你打理好一切。它不会自动创建配置目录、日志目录，也不会建立专用的运行用户。如果直接启动 masterha_manager，很可能会遇到 No such file or directory: /etc/masterha/app1.cnf 这类错误，或者因为权限问题导致日志写入失败。
- 必须手动创建配置目录，例如
/etc/masterha/，并确保运行用户（通常是root或你指定的用户）拥有读写权限。 - 强烈建议为Manager创建一个专用系统用户，例如
useradd -r -s /sbin/nologin mha，并在启动命令中通过--user=mha参数指定，这有助于权限隔离和管理。 - 配置文件的名字必须和启动命令严格对应。比如，如果你用
masterha_manager --conf=/etc/masterha/app1.cnf启动，那么配置文件就必须命名为app1.cnf，叫成mysql-mha.cnf可不行。 - 配置文件里定义的
manager_workdir（工作目录）和manager_log（日志文件）路径，需要提前用mkdir -p创建好，并设置正确的权限。否则，Manager可能看似启动成功，实则监控功能完全失效，因为日志根本写不进去。
SSH免密登录：必须用root，并关掉 requiretty
MHA Manager默认会以 root 用户身份通过SSH连接到各个节点执行命令。如果出于安全考虑想改用普通用户（比如 mysql），就需要在所有节点的 /etc/sudoers 文件中精确授权该用户执行特定命令，这个过程极易遗漏，带来隐患。更常见的问题是触发 sudo: sorry, you must ha ve a tty to run sudo 错误，导致切换流程意外中断。
- 在所有MySQL节点的
/etc/sudoers文件中，务必确认Defaults requiretty这一行被注释掉了。或者，可以添加Defaults:mha !requiretty来针对MHA用户禁用tty要求。 - 在Manager节点生成SSH密钥后，推荐使用
ssh-copy-id root@目标IP命令来分发公钥。不要手动去编辑authorized_keys文件，因为很容易把文件权限设错（比如设成644），导致SSH出于安全考虑拒绝读取。 - 测试SSH连通性时，记得加上
-o StrictHostKeyChecking=no参数，例如ssh -o StrictHostKeyChecking=no root@192.168.1.11 'hostname'。这样可以避免首次连接时出现交互式确认提示，卡住自动化流程。 - 如果Node节点上的
/root/.ssh/config文件配置了Host别名或ProxyCommand等规则，可能会干扰Manager的直接连接判断。为求稳妥，在部署阶段建议先清空或注释掉该文件的内容。
配置文件里最容易遗漏的三个“硬核”字段
app1.cnf 配置文件可不是随便填几项就能跑的。缺少以下任何一个字段，masterha_check_ssh 或 masterha_check_repl 检查命令都会直接报错退出，而不是给出警告。
user=root：注意，这个字段指的是SSH登录用的系统用户，不是MySQL数据库用户。如果不写，默认会使用当前shell用户，而这往往不是root。repl_user=repl和repl_password=replpass：这两个值必须与在MySQL中通过CREATE USER 'repl'@'%'创建的复制账号完全一致，包括大小写、是否使用引号、特殊字符等，都需要仔细核对。ssh_user=root：这是显式声明SSH用户的字段，其值通常和上面的user相同。但在MHA的一些旧版本（比如0.56）中，可能会忽略user而只认ssh_user。所以，最稳妥的做法是两个字段都明确写上。- 另外，
master_ip_failover_script这个配置项也不要留空或仅仅注释掉。即使你当前不打算使用虚拟IP（VIP），也需要将它指向一个实际存在且可执行的脚本（哪怕是一个内容为空的脚本），否则masterha_manager启动时会报Can't open master_ip_failover_script错误。
在实际部署中，超过80%的初始化失败都卡在三个地方：Node没有在所有节点安装齐全、SSH权限配置不对、或者配置文件里少写了某个等号后面的值。一个高效的排查顺序是：先确保 masterha_check_ssh --conf=/etc/masterha/app1.cnf 和 masterha_check_repl --conf=/etc/masterha/app1.cnf 这两条检查命令都能顺利通过，然后再去启动Manager服务。这比反复重启Manager、在日志里大海捞针要节省大量时间。
