必须用独立replication用户而非root，因其仅具备拉取binlog和建立复制连接的细粒度权限，严格遵循最小权限原则，可避免权限失控、审计困难及安全策略失效；mysql 5.7支持grant隐式建用户，8.0必须显式create user，否则报error 1410。
为什么要用独立的REPLICATION用户，而不是root
直接用 root 账户做主从复制，看似省事，但会带来权限失控、审计困难、安全策略失效三个实际问题。MySQL 的 REPLICATION SLAVE 权限是细粒度的，只允许拉取 binlog 和建立复制连接，不涉及任何数据读写或 DDL 操作——这是最小权限原则的刚性要求。生产环境被扫出弱口令 root 账号后横向渗透，80% 以上都源于主从配置误用超级账号。
CREATE USER + GRANT 的标准写法（含 MySQL 5.7/8.0 差异）
MySQL 5.7 和 8.0 在账户创建流程上有关键区别：5.7 允许在 GRANT 时隐式创建用户；8.0 必须显式 CREATE USER，否则报错 ERROR 1410 (42000): You are not allowed to create a user with GRANT。
- 统一推荐写法（兼容 5.7+ 和 8.0+）：
CREATE USER 'repl'@'192.168.131.1' IDENTIFIED BY 'StrongPass!2026'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.131.1'; FLUSH PRIVILEGES;
注意点：
-
'repl'@'192.168.131.1'中的 IP 必须是**从库发起连接时源地址**，不是从库物理 IP（比如 NAT 环境下是网关 IP，见错误日志中提示的Access denied for user 'repl'@'192.168.131.1'） - 密码必须满足当前 MySQL 的
validate_password策略，否则CREATE USER直接失败 - 不要用
'repl'@'%'，除非你明确接受任意 IP 连接——这在云环境等同于暴露复制通道
常见连不上主库的错误和对应检查项
从库执行 CHANGE MASTER TO 后，SHOW SLAVE STATUS\G 显示 Slave_IO_Running: No，且 Last_IO_Error 提示认证失败，大概率是用户配置环节出了问题。
-
ERROR 1045 (28000): Access denied for user 'repl'@'x.x.x.x'：检查CREATE USER语句里的 host 是否与从库实际出口 IP 一致（查主库/var/log/mysqld.log或SELECT USER(), CURRENT_USER();） -
ERROR 2003 (HY000): Can't connect to MySQL server on 'master_ip'：先确认网络层通（telnet master_ip 3306），再确认主库bind-address没有绑定为127.0.0.1 -
ERROR 3021 (HY000): The slave I/O thread stops because master and slave have equal MySQL server ids：检查主从server-id是否重复，该值在my.cnf中，修改后必须重启 mysqld
为什么 FLUSH PRIVILEGES 不可省略
MySQL 的权限表（mysql.user 等）加载进内存后不会自动刷新。即使你已插入新用户记录，若不执行 FLUSH PRIVILEGES，mysqld 仍按旧缓存校验权限，导致从库始终连不上。这不是“有时需要”，而是每次新建复制用户后的强制步骤。跳过它，SHOW GRANTS FOR 'repl'@'...'; 可能显示权限，但实际连接仍失败——因为权限没真正生效。
