mysql只读节点同步主库需主库上授予replication slave权限（必要）及replication client（gtid模式下推荐），用户须从从库ip可连接，且change replication source to中用户名密码配置正确。
mysql只读节点需要什么权限才能同步主库
只读节点（Replica）本身不靠「登录用户」执行业务查询，而是靠 CHANGE REPLICATION SOURCE TO（或旧版 CHANGE MASTER TO）里指定的用户，去主库拉取 binlog。这个用户必须有 REPLICATION SLAVE 权限——不是 SELECT，也不是 REPLICATION CLIENT，缺它就起不来 IO 线程。
常见错误现象：SHOW REPLICA STATUS\G 显示 IO_Running: No，Seconds_Behind_Master: NULL，且 Last_IO_Error 类似 Access denied; you need (at least one of) the SUPER, REPLICATION SLAVE privilege(s) for this operation —— 实际是主库上那个同步用户没给对权限。
- 权限必须在主库上授予，不是在从库
- 只授
REPLICATION SLAVE即可，不需要SELECT或其他表级权限 - 如果主库开了
require_row_format或启用了 GTID，该用户还必须能执行SHOW MASTER STATUS（所以通常顺带加REPLICATION CLIENT更稳妥）
创建只读节点专用同步用户的正确 SQL
别用 root 或业务账号复用，专号专用更安全、权限更收敛。用户要能从从库 IP 连入主库（注意防火墙和 bind-address），密码建议用强随机字符串。
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.%';
如果主库启用了 GTID（gtid_mode = ON），再加一条：
GRANT REPLICATION CLIENT ON *.* TO 'repl_user'@'192.168.10.%';
- 主机段用
'192.168.10.%'比'%'安全，避免暴露到公网 - 不要用
IDENTIFIED BY（老语法），MySQL 8.0+ 推荐显式写IDENTIFIED WITH mysql_native_password BY，避免插件不匹配导致连不上 - 执行完记得
FLUSH PRIVILEGES;，但多数情况下不是必须——因为GRANT自动刷新
配置从库时如何正确引用这个用户
在从库执行 CHANGE REPLICATION SOURCE TO 时，SOURCE_USER 必须和主库上创建的用户名完全一致（包括大小写），密码不能漏掉，且不能加引号包裹密码值。
CHANGE REPLICATION SOURCE TO SOURCE_HOST='192.168.10.100', SOURCE_USER='repl_user', SOURCE_PASSWORD='aB3#xY9!qL2$', SOURCE_PORT=3306, SOURCE_AUTO_POSITION=1;
容易踩的坑：
-
SOURCE_PASSWORD的值不能用单引号或双引号包裹（MySQL 会当字面量处理，导致认证失败） - 如果主库是 MySQL 5.7，用
MASTER_USER/MASTER_PASSWORD，不是SOURCE_*前缀 - 启用了 SELinux 或 AppArmor 的系统，可能拦截从库发起的出站连接，需检查
ausearch -m avc -ts recent日志 - 主库
bind_address如果是127.0.0.1，从库根本连不上——得设成0.0.0.0或具体内网 IP
为什么 SHOW REPLICA STATUS 显示延迟但 IO_Running 是 Yes
说明同步用户权限没问题，IO 线程已连上主库并持续拉日志，问题出在 SQL 线程（回放层）。这时候查 Seconds_Behind_Master 和 SQL_Running_State 更有用。
典型表现：SQL_Running: Yes 但 Seconds_Behind_Master 持续增长，SQL_Running_State 卡在 Waiting for dependent transaction to commit 或 Reading event from the relay log。
- 如果是 GTID 复制，确认主从
gtid_executed是否断裂（SELECT @@global.gtid_executed;对比） - 从库开了
read_only=ON是必须的，但如果误设了super_read_only=ON，SQL 线程会被阻塞（即使read_only=OFF也不行） - 大事务、DDL、或者从库磁盘 I/O 慢，都会拖慢 SQL 线程——这不是权限问题，但常被误判为同步用户配置失败
实际配的时候，最易忽略的是主库的网络可达性与用户 host 段匹配——权限给了、命令敲对了，结果卡在 TCP 层连都连不上。
