mysql如何配置MHA高可用集群_安装Node节点与Manager监控脚本

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、在日志里大海捞针要节省大量时间。