复制账户必须有 REPLICATION SLAVE 权限，否则 CHANGE REPLICATION SOURCE TO 失败、START REPLICA 后 Replica_IO_Running 为 No；无需 SELECT 等数据权限；建议 MySQL 8.0.23+ 额外授予 REPLICATION CLIENT。
复制账户必须有 REPLICATION SLAVE 权限
这是唯一强制要求的权限，没有它，从库连 CHANGE REPLICATION SOURCE TO 都会失败，启动 START REPLICA 后 Replica_IO_Running 直接显示 No，错误日志里通常出现 Access denied; you need (at least one of) the SUPER, REPLICATION SLAVE privilege(s)。注意：不需要 SELECT、SHOW DATABASES 或任何数据读写权限——复制线程只拉取 binlog 内容，不查表。
-
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.10';（生产环境务必限定 IP，不用'%'） - MySQL 8.0.23+ 还建议加上
REPLICATION CLIENT，用于执行SHOW REPLICA STATUS等监控命令 - 旧版（GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'...';
主库是否需要 binlog_format = ROW？不是权限问题，但影响一致性
虽然 REPLICATION SLAVE 权限本身不依赖 binlog 格式，但若用 STATEMENT 模式，NOW()、UUID()、自增列、非确定函数等会导致主从数据不一致——这不是权限缺失，而是语义漂移。所以配置时必须在主库 my.cnf 中显式设为：
-
binlog-format = ROW（MySQL 5.7+ 推荐，8.0 默认） - 验证：登录主库执行
SHOW VARIABLES LIKE 'binlog_format';，返回值必须是ROW - 仅靠权限正确 ≠ 复制可靠；格式错，
Slave_SQL_Running可能是Yes，但数据早就不对了
为什么 SHOW MASTER STATUS 要在创建用户后执行？
因为 CREATE USER 和 GRANT 本身也会写入 binlog（除非禁用 sql_log_bin），如果你先记下 SHOW MASTER STATUS 的位置，再建用户授权，那从库起始同步点就漏掉了这段 DDL 操作——后续从库可能因缺少复制账号而报 Access denied for user 'repl'@...，尤其在 GTID 关闭时更易踩坑。
- 正确顺序：改配置 → 重启 → 创建用户 →
FLUSH PRIVILEGES→ 立刻 执行SHOW MASTER STATUS - 如果主库已有业务流量，且你没锁表，
Position只代表“那一刻”的偏移，不代表绝对一致起点；此时应配合mysqldump --master-data=1或物理备份
常见权限相关报错及定位方法
遇到复制失败，别急着重配，先看 SHOW REPLICA STATUS\G 里的两个字段和错误信息：
-
Replica_IO_Running: No+Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids→ 主从server-id重复，和权限无关，但常被误判 -
Last_IO_Error: Access denied for user 'repl'@'192.168.1.20' (using password: YES)→ 用户不存在、密码错、IP 不匹配，或防火墙拦了 3306 -
Last_SQL_Error: Error 'Table 'test.t1' doesn't exist' on query→ 从库缺表，说明初始数据不一致，权限配置本身没问题，但同步起点错了
权限配置本身不复杂，难的是把「账户存在」「网络通」「binlog 开」「server-id 唯一」「日志位置准」这五件事同时对齐——少一个，REPLICATION SLAVE 就只是个摆设。
