必须用 mysql_native_password 插件创建复制账号，因 mysql 8.0 默认的 caching_sha2_password 不被旧版复制协议支持，会导致从库连接主库时认证失败、io_running: no；需显式指定插件并授予 replication slave、replication client、replication_applier 权限，且 host 需匹配从库真实 ip，密码须高强度，创建后务必手动验证连通性。
必须用 mysql_native_password 插件创建账号，否则从库连接主库时会报错 Plugin caching_sha2_password could not be loaded。
为什么不能直接用 CREATE USER 'repl'@'%' IDENTIFIED BY 'xxx'
MySQL 8.0 默认认证插件是 caching_sha2_password，而旧版复制协议（包括 8.0.22 之前）不支持它。从库在尝试建立复制连接时，会因认证插件不兼容直接失败，错误日志里通常只显示“Access denied”，但 SHOW REPLICA STATUS\G 中的 IO_Running: No 和 Last_IO_Error 字段会暴露真实原因。
正确做法是显式指定插件：
CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'ReplPass123!';- 密码强度必须高：含大小写字母、数字、特殊字符，长度 ≥10；严禁复用业务账号密码
- 若主从都为 8.0.22+ 且已设
master_info_repository=TABLE，可改用START REPLICA USER='repl' PASSWORD='xxx'方式，避免密码明文落盘
GRANT 权限不能只给 REPLICATION SLAVE
仅授权 REPLICATION SLAVE 会导致从库无法获取 GTID 位点或查询主库状态，尤其在开启 gtid_mode = ON 的环境下，START REPLICA 会卡住或报 Could not initialize master info structure。
必须组合授予以下权限：
-
REPLICATION SLAVE：基础复制权限 -
REPLICATION CLIENT：允许执行SHOW MASTER STATUS、SHOW BINLOG EVENTS等诊断命令 -
REPLICATION_APPLIER：GTID 复制必需（MySQL 8.0.17+ 强制要求）
完整授权语句：
GRANT REPLICATION SLAVE, REPLICATION CLIENT, REPLICATION_APPLIER ON *.* TO 'repl'@'%';
执行后务必 FLUSH PRIVILEGES;，否则权限不生效。
账号的 host 部分要匹配从库发起连接的真实 IP
写成 'repl'@'%' 虽方便，但在生产环境有安全风险；更稳妥的是限定具体从库 IP，比如 'repl'@'192.168.152.73'。注意：
- 如果从库走 NAT 或代理，需填代理出口 IP，而非内网地址
- Windows 主库 + Linux 从库组合下，防火墙常拦截连接，建议先用
mysql -h 主库IP -u repl -p手动测试连通性 - 若主库 bind-address 未放开（如默认只绑
127.0.0.1），需在my.cnf中设bind-address = 0.0.0.0或明确指定监听 IP
最容易被忽略的是：账号创建后没验证是否真能连——别等 START REPLICA 报错才回头查。用从库机器执行一次 mysql -h 主库IP -u repl -p -e "SELECT 1"，能通再往下走。否则所有后续配置都是空中楼阁。
