Replication账号必须严格授予REPLICATION SLAVE权限（GTID模式还需REPLICATION CLIENT），host须与从库真实出口IP完全一致，且必须执行FLUSH PRIVILEGES生效；权限缺失或host不匹配将导致IO线程卡在“Connecting to master”，无法拉取binlog。
Replication账号不是“能连上就行”，而是IO线程的唯一凭证
从库的IO线程连接主库时，不走普通客户端协议栈，它用的是MySQL内部复制协议（COM_BINLOG_DUMP），这个协议要求认证用户必须持有REPLICATION SLAVE权限。没有这个权限，哪怕密码正确、网络通、端口开，IO线程也会在“Connecting to master”状态卡死，日志里只显示ERROR 1236 (HY000): Could not open log file或Access denied; you need (at least one of) the SUPER or REPLICATION SLAVE privilege(s)。
给应用账号加REPLICATION SLAVE等于打开后门
很多同学图省事，直接把业务账号（比如app_user）加上REPLICATION SLAVE权限。这会导致两个严重问题：
- 一旦该账号泄露或被注入，攻击者可直接从主库拉取全量binlog，还原出所有写操作，包括敏感字段（如密码重置token、身份证号）
- 如果该账号还有
UPDATE或DROP权限，攻击者可在从库执行STOP SLAVE; SET GLOBAL sql_slave_skip_counter=1; START SLAVE跳过校验，再往从库写脏数据，破坏主从一致性 - DBA审计时无法区分“谁在同步”和“谁在查数”，权限边界彻底模糊
host匹配错误比权限漏授更常见
权限没给对还能报错，但host写错会静默失败——IO线程连得上，却始终不拉日志。关键点：
-
CREATE USER 'repl'@'192.168.5.20'和GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.5.20'必须完全一致，'repl'@'%'和'repl'@'192.168.5.%'是不同账号 - MySQL 8.0+默认用
caching_sha2_password插件，'repl'@'%'无法远程认证，必须显式指定从库真实出口IP - 如果从库在Docker里跑，宿主机
ifconfig看到的IP不是容器内网IP，而是Docker网桥地址（如172.17.0.2），host得填这个
GTID模式下REPLICATION CLIENT不是可选，是刚需
启用GTID后，从库启动时会自动执行SELECT @@global.gtid_executed来比对事务集合，这个语句需要REPLICATION CLIENT权限。只给REPLICATION SLAVE会导致START SLAVE直接报错：ERROR 1227 (42000): Access denied。实操中建议统一授予：
CREATE USER 'repl'@'192.168.5.20' IDENTIFIED BY 'strong_pass_2024'; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'192.168.5.20'; FLUSH PRIVILEGES;
真正容易被忽略的不是“要不要给”，而是FLUSH PRIVILEGES这一步——权限表缓存在内存，不刷就不会生效，哪怕你刚GRANT完也白搭。
