mysql主从复制账号只需replication slave权限，无需replication client等额外权限；必须使用从库真实ip（如'repl'@'192.168.1.102'）而非localhost创建账号，并显式执行create user与grant，最后验证连接。
MySQL主从复制账号需要哪些最小权限？
只给 REPLICATION SLAVE 权限就足够了，不需要 REPLICATION CLIENT 或其他额外权限。这个权限专用于让从库连接主库并读取二进制日志，权限粒度精准、攻击面小。
常见错误是顺手加 SELECT 或 SHOW DATABASES，其实从库账号根本用不到这些——它不查表、不列库，只拉 binlog 事件。
-
REPLICATION SLAVE是唯一必需权限 - 账号必须能从从库所在 IP（或
%）连接主库，注意防火墙和bind-address配置 - 避免使用
root或已有高权限账号做复制用户，违背最小权限原则
创建账号时为什么不能用 localhost？
从库连接主库走的是 TCP 网络连接，即使主从在同一台机器，也默认用主机名/IP 连接，'repl'@'localhost' 在绝大多数情况下无法匹配成功。
典型表现是执行 CHANGE REPLICATION SOURCE TO 后，SHOW REPLICA STATUS 显示 IO_Running: Connecting 卡住，查 SHOW SLAVE HOSTS 或主库的 SHOW PROCESSLIST 会看到连接被拒绝或无记录。
- 正确写法是
'repl'@'192.168.1.102'（从库真实 IP），或临时用'repl'@'%'（仅测试环境） - 如果主库启用了
skip-name-resolve，DNS 解析会被跳过，此时'repl'@'hostname'一定失效 - 创建后务必用
SELECT user, host FROM mysql.user WHERE user = 'repl';确认 host 字段值
CREATE USER 和 GRANT 顺序有影响吗？
有。MySQL 8.0+ 强制要求先 CREATE USER 再 GRANT，直接 GRANT 一个不存在的用户会报错 ERROR 1410 (42000): You are not allowed to create a user with GRANT。
MySQL 5.7 虽然允许隐式创建，但行为不一致、易混淆，统一用显式方式更可靠。
- 标准操作两步走：
CREATE USER 'repl'@'192.168.1.102' IDENTIFIED BY 'strong_pass_2024';<br>GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.102';
- 密码强度需满足主库的
validate_password策略，否则CREATE USER报错ERROR 1819 (HY000) - 执行完记得
FLUSH PRIVILEGES;—— 虽然GRANT通常自动刷新，但某些版本或配置下仍需手动触发
验证账号是否真能连上主库？
别等配完从库再排查。在从库机器上用 mysql 客户端直连主库，是最快速有效的验证方式。
容易忽略的是：从库 MySQL 进程本身是否能解析主库地址？是否被 SELinux 或 AppArmor 拦截网络？这些都会导致连接超时，而非权限错误。
- 命令示例：
mysql -h 192.168.1.101 -u repl -p -e "SELECT 1;" - 成功返回
1表示网络通、认证过、权限够；若报Access denied，重点检查user表中的host值和密码；若报Connection refused或超时，查主库port、防火墙、bind-address - 确认主库
SHOW MASTER STATUS有输出且File不为空，否则从库启动复制时会报Could not find first log file name in binary log index file
实际部署时，最常卡在 host 匹配和网络连通性上，而不是权限语法本身。把 CREATE USER 的 host 写对、在从库机器上亲手跑一次 mysql -h 连接，基本就能绕过八成问题。
