复制账号必须只给 REPLICATION SLAVE
权限
复制账号不是普通业务账号，它唯一作用是让从库读取主库的 binlog，因此权限越小越安全。只要授予
REPLICATION SLAVE就够用，多加任何权限（比如
SELECT、
ALL PRIVILEGES或
REPLICATION CLIENT）都是冗余且危险的。
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.11'—— 推荐限定从库 IP，不用
'%'切勿执行
GRANT ALL ON *.*或
GRANT REPLICATION SLAVE, SUPER这类组合 如果误授了多余权限，用
REVOKE ALL PRIVILEGES ON *.* FROM 'repl'@'192.168.1.11'先清空，再重授 授完务必运行
FLUSH PRIVILEGES，否则权限不生效
MySQL 8.0+ 创建用户时要注意认证插件
MySQL 8.0 默认使用
caching_sha2_password插件，而旧版客户端或某些中间件可能不兼容，导致从库连不上主库，报错类似
Authentication plugin 'caching_sha2_password' cannot be loaded。 创建账号时显式指定插件更稳妥：
CREATE USER 'repl'@'192.168.1.11' IDENTIFIED WITH mysql_native_password BY 'StrongPass123!'若已创建但连接失败，可修改：
ALTER USER 'repl'@'192.168.1.11' IDENTIFIED WITH mysql_native_password BY 'StrongPass123!'密码强度策略（如
validate_password_policy）会影响建号，临时调低可用：
SET GLOBAL validate_password_policy = LOW，但仅用于测试环境
账号网络可达性比语法更重要
很多“授权失败”实际是网络或防火墙问题：账号建对了、权限给了、密码也对，但从库就是连不上主库。
先在从库机器上手动测试连通性：mysql -h 192.168.1.10 -u repl -p—— 成功登录才说明账号和网络都 OK 检查主库是否监听公网地址：确认
bind-address没被设成
127.0.0.1（应为
0.0.0.0或具体内网 IP） 确认防火墙放行 3306：
firewall-cmd --permanent --add-port=3306/tcp && firewall-cmd --reload（CentOS）或对应系统命令 云服务器还要检查安全组规则，开放入方向 TCP 3306
SHOW MASTER STATUS
的输出要和 CHANGE MASTER TO
严格一致
从库配置复制关系时，
master_log_file和
master_log_pos必须完全匹配主库当前 binlog 状态，哪怕差一个字节都会导致 IO 线程启动失败，报错如
Got fatal error 1236 from master。 在主库执行
SHOW MASTER STATUS后立刻记录
File和
Position值，不要做任何写操作再查 文件名注意大小写和扩展名：例如
mysql-bin.000004≠
MYSQL-BIN.000004≠
mysql-bin.00004位置值是整数，不能带逗号或单位；若为 0，说明 binlog 刚清空或新启，此时从库需跳过初始数据同步（如已有全量备份）
复制账号本身不难配，真正卡住人的往往是权限粒度没控好、认证插件不兼容、网络不通，或者 binlog 位点抄错了。尤其在 MySQL 8.0+ 环境下，
mysql_native_password和
server-id冲突这两点，几乎必踩一次。
