Access denied for user 'repl'@'%' 是权限同步中断的明确信号，表明从库缺失该账号或权限，根源在于 GRANT 操作未进入 binlog 或被 replicate_ignore_db=mysql 屏蔽；需通过 SHOW SLAVE STATUS\G 检查 Replicate_Ignore_DB，确认主库 log_bin=ON 且未启用 --skip-grant-tables，修复时必须用 CREATE USER + GRANT 语句而非直写 mysql.user 表，并在从库临时创建账号恢复连接。
Access denied for user 'repl'@'%' 是权限同步中断的明确信号
看到 Last_SQL_Error 里出现 Access denied for user 'repl'@'%' (using password: YES)，基本可以确定不是网络不通、也不是主库没开 binlog，而是从库压根没这个账号，或账号没对应权限。根本原因在于：GRANT 操作默认不进 binlog（5.7 及以前），或进了但被 replicate_ignore_db=mysql 屏蔽了——从库根本收不到建账号的语句。
检查 Replicate_Ignore_DB 是否屏蔽了 mysql 库
运行 SHOW SLAVE STATUS\G，重点看 Replicate_Ignore_DB 字段。如果值是 mysql 或包含 mysql，那所有对 mysql.user 的修改（包括 CREATE USER、GRANT）都不会同步到从库。
- 临时验证：在从库执行
SELECT user, host FROM mysql.user WHERE user = 'repl';，返回空就是典型表现 - 不要改配置直接删掉
replicate_ignore_db=mysql——这会触发全量重同步风险；优先走“让权限变更进 binlog”的路径 - 8.0+ 用户需确认
log_bin=ON且未启用--skip-grant-tables（查SELECT @@skip_grant_tables;，必须为 0）
修复必须用 GRANT，别碰 mysql.user 表
手动 INSERT INTO mysql.user 或 UPDATE mysql.user 是高危操作：不触发权限重载、不写 binlog、字段顺序和密码哈希方式极易出错，从库回放时大概率报错中断。
通过 yarn-threads-cli 与 Threads（Meta）交互。当用户想要阅读首页动态、点赞、收藏的帖子或特定帖子时使用；查看...
- 正确做法是在主库执行：
CREATE USER 'repl'@'%' IDENTIFIED BY 'xxx'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; - 若已中断，先
STOP SLAVE;，再在从库本地执行同名账号创建（仅用于恢复连接，非长期方案）：CREATE USER 'repl'@'%' IDENTIFIED BY 'xxx'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; START SLAVE; - 用 GTID 模式时，严禁
SET GLOBAL sql_slave_skip_counter = 1，它不兼容 GTID
确认复制用户具备最小必要权限
REPLICATION SLAVE 是刚需，REPLICATION CLIENT 用于监控主库状态。缺一不可。用 SELECT Repl_slave_priv, Repl_client_priv FROM mysql.user WHERE User = 'repl' AND Host = '%'; 验证是否为 Y。
- 别给
repl用户SUPER权限——这是常见误操作，ERROR 1227报错说明你用了不该用的高危权限 - 主机名用
'%'而非'localhost'，避免 socket/TCP 连接差异导致从库连不上主库 - 密码尽量避开特殊字符，某些旧客户端解析会失败
最易被忽略的一点：修复后必须验证 Slave_SQL_Running 和 Seconds_Behind_Master 是否恢复正常，而不仅是 Slave_IO_Running: Yes——IO 线程连上了，SQL 线程仍可能卡在下一条权限语句上。
