必须限制为从库真实ip，不能用'%'；正确写法如create user 'repl'@'192.168.52.123' identified by 'strong_password_2026'，因'%'会暴露复制通道引发安全风险，且mysql 8.0默认拒绝远程root登录，同理需严格限定ip。
CREATE USER 语句必须用 'repl'@'%' 还是限定具体 IP？
必须限制为从库真实 IP，不能用 '%'。生产环境开放通配符会带来严重安全风险，MySQL 8.0 默认拒绝远程 root 登录，但 'repl'@'%' 同样暴露复制通道。
正确写法示例：CREATE USER 'repl'@'192.168.52.123' IDENTIFIED BY 'strong_password_2026';
- IP 必须与从库实际发起连接的出口 IP 一致（注意 Docker 容器、NAT、云厂商内网地址差异）
- 密码需满足 MySQL 8.0 的默认策略：至少 8 位，含大小写字母+数字+特殊字符
- 若主库启用了
require_secure_transport=ON，该用户还需显式声明使用 SSL：REQUIRE SSL
GRANT REPLICATION SLAVE 权限是否足够？
仅 REPLICATION SLAVE 是最小必要权限，但要注意它不包含 SELECT 或 SHOW DATABASES —— 这意味着该用户无法执行 SHOW MASTER STATUS，也不能跨库查询。
常见错误现象：Access denied; you need (at least one of) the SUPER or REPLICATION CLIENT privilege(s) for this operation，这是因误用该账号去查主库状态导致的。
-
REPLICATION SLAVE只用于从库连接主库拉取 binlog，不要在主库上用它查状态 - 查
SHOW MASTER STATUS必须用root或带REPLICATION CLIENT权限的账号 - 不要额外授予
SUPER—— 它可绕过只读限制，破坏主从一致性
FLUSH PRIVILEGES 是否总要执行？
MySQL 5.7.6+ 中，CREATE USER + GRANT 后无需手动 FLUSH PRIVILEGES；但如果你先 CREATE USER 再单独 GRANT，就必须执行。
最稳妥写法是合并授权一步到位：
CREATE USER 'repl'@'192.168.52.123' IDENTIFIED BY 'P@ssw0rd2026'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.52.123';
此时可省略 FLUSH PRIVILEGES。如果已执行过 GRANT 但没生效，再补一句也无害。
- MySQL 8.0 默认启用
caching_sha2_password插件，旧客户端可能连不上 —— 若报错Authentication plugin 'caching_sha2_password' cannot be loaded，建用户时加IDENTIFIED WITH mysql_native_password - 防火墙必须放行主库 3306 端口到从库 IP，否则
CHANGE MASTER TO会卡在连接超时
为什么从库 START SLAVE 后报错 "Could not find first log file name in binary log index file"？
这不是用户权限问题，而是 CHANGE MASTER TO 中的 MASTER_LOG_FILE 值错误 —— 通常因为主库重启或日志轮转后，SHOW MASTER STATUS 返回的 File 已被删除，而复制用户没权限读取 mysql-bin.index 查看可用日志列表。
根本原因：复制用户只能拉取 binlog，不能列出 binlog 文件名。所以 MASTER_LOG_FILE 必须严格匹配当前有效的文件（如 mysql-bin.000005），不能填错或用旧值。
- 每次执行
CHANGE MASTER TO前，务必在主库用root执行一次SHOW MASTER STATUS，直接复制输出的File和Position - 避免在主库执行
RESET MASTER—— 它会清空所有 binlog 并重置索引，导致从库无法找到起点 - 若已出错，用
SHOW BINARY LOGS;（需REPLICATION CLIENT）确认当前可用日志，再修正MASTER_LOG_FILE
实际配置中，最容易被忽略的是时间同步和 binlog 文件生命周期管理 —— 主从系统时间差超过 1 秒，或主库 expire_logs_days 设置过短，都可能导致从库拉取日志失败且报错模糊。
