MHA管理账号最小权限为SELECT、REPLICATION CLIENT、REPLICATION SLA VE、RELOAD、SUPER（8.0+可用SYSTEM_VARIABLES_ADMIN+BINLOG_ADMIN替代）；需在所有节点单独创建并验证，禁止GRANT OPTION，配置文件权限设为600。
MySQL MHA 管理账号需要哪些最小权限
给MHA（Master High A vailability）配置管理账号，首先要明确一点：它不负责执行业务SQL。它的核心任务，其实是主从状态探测、故障切换和应用binlog。因此，它依赖的专用账号，权限范围必须精准——既要能在所有节点（包括未来可能被提升的候选主库）上执行关键操作，又要尽可能收紧，避免安全风险。
直接用root账号？或者赋予GRANT OPTION、CREATE USER这类高权限？这都不是好主意。MHA本身不需要创建用户，权限过大反而容易触发安全策略的拦截，比如MySQL 8.0的require_row_format检查，或者系统层面的SELinux限制。
那么，到底需要哪些权限呢？下面这个组合，是经过验证的最小必要集合：
SELECT：用于读取information_schema、performance_schema以及复制相关的系统表（例如，执行SHOW SLA VE STATUS命令时，底层就需要查询这些视图）。REPLICATION CLIENT：这是获取复制状态的关键。有了它，MHA才能查看主从的IO/SQL线程状态、当前的binlog位置以及GTID信息。REPLICATION SLA VE：这个权限允许MHA在故障切换时启动SQL线程（START SLA VE SQL_THREAD），同时也是执行CHANGE MASTER命令指向新主库所必需的。RELOAD：主要用于执行FLUSH LOGS、FLUSH TABLES WITH READ LOCK等命令。后者在旧主库仍可访问时，对于确保切换数据一致性至关重要。SUPER：在MySQL 5.7及更早版本中，这是必需的。到了MySQL 8.0+，理论上可以用SYSTEM_VARIABLES_ADMIN和BINLOG_ADMIN这两个更细粒度的权限来替代。但为了更好的兼容性，尤其是在混合版本环境中，建议仍然授予SUPER权限，除非环境明确禁止。
如何在所有节点统一创建并验证账号
创建账号这一步，有个关键原则：必须在每个节点上单独执行。这里的节点包括当前的主库、所有的从库，以及任何未来可能被提升为备选主库的备用节点。
为什么不能只在主库上创建，然后依赖复制同步到从库呢？原因在于，MHA在进行健康检查（masterha_check_repl）时，会直接连接到每一个节点。如果某个从库上缺少这个管理账号，检查就会失败，报出Can't connect to MySQL server或者更隐蔽的Access denied for user 'mha'@'x.x.x.x'错误。
具体操作上，可以参考下面的SQL语句（这里以用户名mha、密码mha_pass_2024为例）：
CREATE USER 'mha'@'%' IDENTIFIED BY 'mha_pass_2024'; GRANT SELECT, REPLICATION CLIENT, REPLICATION SLA VE, RELOAD, SUPER ON *.* TO 'mha'@'%'; FLUSH PRIVILEGES;
执行时，有几点细节值得注意：
- 主机名设定：建议使用
'%'，而不是绑定某个具体IP。这样可以避免因为MHA脚本运行时解析出的连接IP（例如容器内网地址、跳板机出口IP）与授权IP不匹配而导致连接失败。 - 禁止授权传递：切记不要加上
WITH GRANT OPTION。MHA只需要使用权限，从不负责给其他账号授权。 - 即时验证：账号创建完成后，别等到
masterha_check_repl报错再去排查。应该立即在每个节点上执行类似mysql -umha -pmha_pass_2024 -e "SELECT 1"的命令，验证账号的连通性是否正常。
为什么 masterha_check_repl 显示 “MySQL is not running” 却能连上
这个问题相当常见，而且错误信息极具迷惑性。当你看到“MySQL is not running”的提示时，第一反应可能是数据库服务挂了，但实际通过mysql客户端却能正常连接。问题出在哪？
根本原因，往往不是MySQL进程停止，而是账号权限不足。MHA在内部检查时，会尝试执行SHOW SLA VE STATUS和SELECT @@server_id这类语句。如果账号因为缺少权限（触发ERROR 1227 (42501)）而被拒绝执行其中任何一条，MHA就可能误判为“MySQL not running”。
常见的诱因包括：
- 从库节点漏权：在某个sla ve节点上，忘记授予
REPLICATION CLIENT权限（SHOW SLA VE STATUS命令依赖此权限）。 - MySQL 8.0特定设置：启用了
require_row_format=ON，而账号缺少TABLE_ENCRYPTION_ADMIN权限。这种情况虽然较少，但在某些强制开启此选项的云RDS环境中可能出现。 - SQL模式拦截：在
sql_mode=STRICT_TRANS_TABLES等严格模式下，旧版MHA脚本如果传递了空字符串作为server_id等参数，可能因隐式类型转换问题而被拦截。
如何诊断？一个有效的方法是：手动使用MHA管理账号登录到报错的节点，然后逐条执行MHA日志中、在报错信息出现之前最后记录的那条SQL语句，观察是否返回权限相关的错误。
配置文件中 user 和 password 怎么写才安全
MHA的配置文件（比如/etc/app1.cnf）里，user和password字段是以明文形式存储的。这是由MHA的设计机制决定的——它的进程需要直接读取这些信息，目前无法对接外部的密钥管理服务。
那么，安全性的重点就不在于加密配置文件内容本身，而在于严格控制文件的访问权限：
- 权限收紧：将配置文件的属主设置为运行MHA服务的专用系统用户（例如
mha），并将文件权限严格设置为600（仅属主可读写）。命令示例：chown mha:mha /etc/app1.cnf && chmod 600 /etc/app1.cnf。 - 避免混淆：不要将密码写在
~/.my.cnf中指望MHA去读取。MHA并不识别这个文件，而且该文件可能被其他进程读取，增加泄露风险。 - 自动化部署时的管理：如果使用Ansible、SaltStack等工具管理集群，密码应存储在vault等加密存储中。在通过模板渲染生成配置文件时注入，并在渲染完成后立即清理内存中的相关变量。
还有一个容易被忽略的细节：MHA的masterha_manager进程启动后，其命令行参数（包含配置文件的路径）可以通过ps aux | grep masterha_manager命令查看到。因此，配置文件本身的路径也不要暴露过于敏感的目录结构，避免使用像/etc/mha/conf/mha_user_mha_pass.cnf这种包含账号信息的命名方式。
