MySQL创建MHA监控账号需执行CREATE USER 'mha_monitor'@'%' IDENTIFIED BY 'your_strong_password'，再授予SELECT、RELOAD、SUPER、REPLICATION CLIENT ON .权限，并FLUSH PRIVILEGES；必须避免复用repl账号或root，且需确保认证插件兼容、网络可达、bind_address配置正确。
mysql如何创建MHA监控账号并授权
为MHA Manager配置一个专用的数据库账号，这事儿可不能马虎。这个账号的核心任务是什么？就是检测主从状态、读取复制信息，以及在触发切换前完成各项检查。如果只给它一个简单的SELECT权限，那么运行masterha_check_repl时，你很可能会遇到“Access denied for operation REPLICATION CLIENT”这样的报错。所以，必须显式地授予一组特定的权限。这里有个常见的误区：以为授予ALL PRIVILEGES就万事大吉了。实际上，在某些MySQL版本（比如8.0及以上）中，ALL PRIVILEGES并不包含REPLICATION CLIENT这个关键权限。
那么，具体需要哪些权限呢？我们逐一拆解：
REPLICATION CLIENT：这是必需的。没有它，账号就无法执行SHOW MASTER STATUS和SHOW SLA VE STATUS这类关键命令。SELECT：同样是必需的。主要用于查询information_schema以及复制相关的系统表，例如performance_schema.replication_connection_status。RELOAD：也是必需的。MHA在进行故障切换时，可能会调用FLUSH LOGS等维护操作，这个权限就是为此准备的。SUPER：这个权限至关重要。当需要提升一个新的主库时，MHA必须能够执行RESET SLA VE ALL和CHANGE MASTER TO这类高权限命令。
明白了权限构成，操作就清晰了。推荐在主库上执行以下SQL语句（请务必将'mha_monitor'和密码替换成你自己的强密码）：
CREATE USER 'mha_monitor'@'%' IDENTIFIED BY 'your_strong_password'; GRANT SELECT, RELOAD, SUPER, REPLICATION CLIENT ON *.* TO 'mha_monitor'@'%'; FLUSH PRIVILEGES;
为什么不能用root或复制账号复用
有些朋友图省事，想直接复用现有的repl复制账号或者干脆用root，这其实埋下了隐患。
先说repl账号，它通常只被授予了REPLICATION SLA VE权限，而严重缺少MHA监控所必需的REPLICATION CLIENT和SUPER权限。
那用root呢？这直接违反了安全领域最基本的“最小权限原则”。不仅如此，在实践中，MHA的日志里会频繁出现Access denied警告，尤其是在MySQL 8.0+版本中，如果启用了require_row_format或在sql_log_bin=OFF的上下文中操作时，问题会更突出。
除了权限本身，还有几个配置细节需要特别注意：
- 认证插件：MySQL 8.0+默认使用
caching_sha2_password认证插件。你需要确认mha_monitor账号使用的是mysql_native_password，否则传统的MHA Perl脚本很可能会连接失败。 - 连接安全：如果数据库集群启用了
require_secure_transport=ON，那么这个监控账号的所有连接都必须走SSL加密通道。否则，即使masterha_check_ssh能通过，masterha_check_repl也会因为连接被拒绝而失败。 - 访问主机：账号的host部分，建议使用
'%'而不是某个具体的IP地址。因为MHA Manager可能会从集群中的任意节点发起探测请求，特别是当Manager本身部署在某台Sla ve服务器上时，这种灵活性尤为重要。
验证权限是否生效
权限授予完成后，千万别以为只看一眼SHOW GRANTS的输出就完事了。最可靠的方式，是模拟MHA的实际行为进行测试：
- 测试主库连通性：在MHA Manager节点上，尝试用这个账号连接主库并执行关键命令：
mysql -umha_monitor -pyour_strong_password -h192.168.1.10 -e "SHOW MASTER STATUS;" - 测试从库信息读取：在任意一台从库上，用同样的账号执行：
mysql -umha_monitor -pyour_strong_password -h192.168.1.11 -e "SHOW SLA VE STATUS\G"，确认能够正常返回Seconds_Behind_Master等复制状态字段。 - 运行MHA检查命令：最后，执行正式的检查命令：
masterha_check_repl --conf=/etc/mha/app.cnf，仔细观察输出日志中是否还存在Can't connect to MySQL server或Access denied这类错误信息。
这里有一个最容易被忽略的“坑”：即使所有权限都配置得完美无缺，如果MySQL服务器的bind_address参数被设置为127.0.0.10.0.0.0或服务器对外的网卡IP地址，同时确保防火墙已经放行了3306端口。这一步没做，前面所有的努力都可能白费。
