MySQL 8.0+主从复制账号必须分两步创建：先CREATE USER显式指定mysql_native_password插件，再GRANT REPLICATION SLAVE（GTID模式需额外加REPLICATION CLIENT），且host须限定为从库IP或网段，严禁用'%'，授完执行FLUSH PRIVILEGES并手动验证连通性与权限。
CREATE USER 和 GRANT 必须分两步执行
MySQL 8.0+ 不允许在 GRANT 时隐式创建用户，直接运行 GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.10.50' IDENTIFIED BY 'pwd' 会报错 ERROR 1410 (42000): You are not allowed to create a user with GRANT。必须先显式创建用户，再授权。
-
CREATE USER 'repl'@'192.168.10.50' IDENTIFIED WITH mysql_native_password BY 'aB3#xY9!qL2$'—— 显式指定认证插件，避免从库客户端不兼容caching_sha2_password -
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.10.50'—— 权限只能作用于*.*，不能限定库或表 - 执行完务必
FLUSH PRIVILEGES，某些配置下权限不会自动生效
REPLICATION SLAVE 是唯一必需权限，但 GTID 模式下需额外加 REPLICATION CLIENT
如果主库启用了 gtid_mode = ON，仅 REPLICATION SLAVE 不够。从库启动时会尝试执行 SHOW MASTER STATUS 获取初始位点，该操作需要 REPLICATION CLIENT 权限，否则报错 Access denied; you need REPLICATION CLIENT privilege。
- 非 GTID 环境：只授
REPLICATION SLAVE即可 - GTID 环境：必须同时执行
GRANT REPLICATION CLIENT ON *.* TO 'repl'@'192.168.10.50' - 绝对不要顺手加
SELECT、SHOW DATABASES或ALL PRIVILEGES—— 从库账号只读 binlog，不查表、不列库
host 字段写成 '%' 是高危操作，必须精确到从库 IP 或网段
用 'repl'@'%' 创建账号看似省事，但等于开放给任意 IP 连接主库的 3306 端口，极易被爆破或滥用。生产环境必须限制 host 范围。
- 推荐写法：
'repl'@'192.168.10.50'（单 IP）或'repl'@'192.168.10.%'（C 类网段） - 禁止用
'repl'@'localhost'—— 从库走 TCP 连接，即使与主库同机也匹配不到 - 执行后立即验证：
SELECT user, host FROM mysql.user WHERE user = 'repl'，确认host字段值符合预期
账号连通性必须在配从库前手动验证
别等 CHANGE REPLICATION SOURCE TO 执行完再排查连接问题。IO_Running: Connecting 卡住，90% 是账号或网络问题，而非复制配置本身。
- 从从库机器执行：
mysql -h -u repl -p -P 3306，输入密码看是否能登录 - 登录后立即执行：
SHOW GRANTS FOR CURRENT_USER()，确认返回中包含REPLICATION SLAVE - 检查主库防火墙是否放行 3306，以及
bind-address是否配置为0.0.0.0或具体监听 IP，而非127.0.0.1
真正容易被忽略的是：账号 host 值和 GTID 模式下的权限组合必须严格匹配，且验证动作不能跳过。这两个点出错，同步永远卡在 IO 线程初始化阶段，日志里只显示“Connecting”，没有更具体的错误提示。
