复制账号只需 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.1Linux 防火墙是否放行 3306？
sudo ufw status或
sudo firewall-cmd --list-ports云服务器安全组是否允许从库 IP 访问主库 3306 端口？ SELinux 是否阻止 mysqld 网络连接？临时测试可
sudo setenforce 0MySQL 是否配置了
skip-networking=ON？该选项会彻底禁用 TCP 连接
真正难调试的从来不是授权语句本身，而是权限生效的前提条件——网络通、服务听、日志开、ID 唯一。每一步都得验证，而不是“应该没问题”。
