必须在主库执行GRANT REPLICATION SLAVE，因为从库I/O线程需用该账号连接主库拉取binlog，权限必须在主库授予且仅对.有效；若写'%'、漏REPLICATION CLIENT（GTID场景）或网络配置错误，均导致IO_Running: No。
必须在主库上创建并授权，且账号主机段不能写成 '%' —— 否则从库连不上、IO_Running: No 是必然结果。
为什么必须在主库执行 GRANT REPLICATION SLAVE
从库的 I/O 线程是主动连接主库拉取 binlog 的，它用的是 CHANGE REPLICATION SOURCE TO 里指定的 SOURCE_USER 和 SOURCE_PASSWORD。这个用户必须能在主库完成身份验证，并有权限读取 binlog 文件。权限配在从库、或者用业务账号复用，都会直接失败。
常见错误现象：SHOW SLAVE STATUS\G 中 IO_Running: No，Last_IO_Error 显示 Access denied for user 'repl'@'192.168.10.50' 或类似连接拒绝信息。
- 权限语句必须在主库 MySQL 实例中执行，不是从库
-
REPLICATION SLAVE权限只对*.*有效，不能限定库或表（如ON mydb.*会静默忽略） - MySQL 8.0+ 默认认证插件是
caching_sha2_password，若从库客户端版本旧（如 MySQL 5.7 客户端），需显式指定IDENTIFIED WITH mysql_native_password
CREATE USER 和 GRANT 的正确写法（含 GTID 场景）
很多团队只执行一条 GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.10.%' 就以为完事，结果启动复制时报错 Access denied; you need REPLICATION CLIENT privilege —— 这是因为主库启用了 GTID（gtid_mode = ON），从库初始化时会执行 SHOW MASTER STATUS，这需要额外权限。
正确组合（缺一不可）：
CREATE USER 'repl_user'@'192.168.10.%' IDENTIFIED WITH mysql_native_password BY 'aB3#xY9!qL2$'; GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'192.168.10.%'; GRANT REPLICATION CLIENT ON *.* TO 'repl_user'@'192.168.10.%'; FLUSH PRIVILEGES;
- 主机段推荐写成
'192.168.10.%'或精确 IP（如'192.168.10.50'），禁用'%'防止暴露到公网 - 用户名区分大小写，
'Repl_User'和'repl_user'是两个不同账号 - 密码不能加单引号包裹在
GRANT语句里（常见手误：GRANT ... BY 'pass'是错的；密码只在CREATE USER或ALTER USER中出现）
主库网络与配置的三个硬性前提
即使 SQL 授权全对，只要以下任一条件不满足，从库照样连不上主库：
- 主库
bind-address不能是127.0.0.1，得设为0.0.0.0或具体内网 IP，否则拒绝远程连接 - 主库防火墙/安全组必须放行从库 IP 对 3306 端口的入向连接（注意：是主库开 3306 入口，不是从库）
- 主库必须启用 binlog，且
server-id已设置（server-id=1即可，但不能为 0 或重复）
验证方式：mysql -h 主库IP -u repl_user -p -P 3306 能登录成功，才说明网络 + 账号 + 权限三者都通。
最容易被忽略的是：GTID 模式下漏掉 REPLICATION CLIENT，以及主机段写成 '%' 后被安全审计驳回。这两点在生产环境上线前务必交叉确认。
