复制账号只需 REPLICATION SLAVE 权限，且必须限定来源 IP、强密码并确保网络与日志配置正确；其他权限既不必要又增加风险。
复制账号只需 REPLICATION SLAVE 权限，别多给也别少给
MySQL 主从复制中，从库连接主库时使用的账号，**唯一必需的权限就是 REPLICATION SLAVE**。它专用于让从库读取主库的二进制日志（binlog），不涉及数据查询、修改或管理操作。
常见错误是顺手给 SELECT、ALL PRIVILEGES 甚至 GRANT OPTION——这既无必要，又增加安全风险。生产环境尤其要避免：
-
REPLICATION SLAVE已足够启动 IO 线程拉取日志 - 不需要
SELECT：从库同步靠 relay log 回放，不走主库 SELECT 查询 - 禁止
SUPER或SHUTDOWN等高危权限 - 若后续启用 GTID 复制，仍无需额外授权，
REPLICATION SLAVE依然够用
创建账号时 'repl'@'%' 要收紧，别留后门
开发环境图省事写 'repl'@'%'，上线必须改掉。% 允许任意 IP 连接，等于把 binlog 通道暴露在公网。
实操建议：
- 明确指定从库 IP，例如
'repl'@'192.168.5.22'（单从库）或'repl'@'192.168.5.%'（同网段多从库） - 避免使用
'repl'@'localhost'：从库通常远程连接，localhost 仅限本地 socket，无法生效 - 密码必须强口令，且避免明文硬编码在
CHANGE MASTER TO语句里（MySQL 8.0+ 支持使用MASTER_USER+ 密码文件方式增强安全性） - 执行完记得
FLUSH PRIVILEGES，否则权限不生效——这个步骤常被跳过，导致Access denied报错
SHOW MASTER STATUS 不是授权动作，但它是同步起点
很多人误以为授权完就能直接 START SLAVE，结果卡在 Slave_IO_Running: No。根本原因常是没获取正确的同步起点。SHOW MASTER STATUS 返回的 File 和 Position 值，是 CHANGE MASTER TO 中 MASTER_LOG_FILE 和 MASTER_LOG_POS 的唯一合法来源。
注意：
- 该命令必须在主库上执行，且主库已开启
log-bin并重启过 - 如果主库已有业务流量，建议先
FLUSH TABLES WITH READ LOCK再查位置，确保一致性（从库初始化时尤其关键） - 若主库启用了 GTID，就不用记 Position，改用
MASTER_AUTO_POSITION = 1，此时权限要求不变，但配置逻辑不同
防火墙、SELinux、skip-networking 都可能让授权“看起来生效”实则连不上
权限给了、账号建了、SHOW GRANTS 也显示正确，但从库仍报 ERROR 2003 (HY000): Can't connect to MySQL server 或 Access denied for user——大概率不是权限问题，而是网络/系统层拦截。
排查优先级：
- 主库是否监听非本地地址？检查
bind-address是否为0.0.0.0或具体内网 IP，而非127.0.0.1 - Linux 防火墙是否放行 3306？
sudo ufw status或sudo firewall-cmd --list-ports - 云服务器安全组是否允许从库 IP 访问主库 3306 端口？
- SELinux 是否阻止 mysqld 网络连接？临时测试可
sudo setenforce 0 - MySQL 是否配置了
skip-networking=ON？该选项会彻底禁用 TCP 连接
真正难调试的从来不是授权语句本身，而是权限生效的前提条件——网络通、服务听、日志开、ID 唯一。每一步都得验证，而不是“应该没问题”。
