SHOW SLAVE STATUS\G 是排查主从权限同步失败的唯一入口，重点检查 Last_SQL_Error 是否含 Access denied 等权限错误，并确认 mysql 库未被 replicate_ignore_db 屏蔽、主库 binlog 已开启、无 --skip-grant-tables 及 read_only 干扰。
SHOW SLAVE STATUS\G 是唯一入口，先看 Last_SQL_Error 是否含 Access denied、ERROR 1045 或 ERROR 1141 —— 这类错误基本锁定为权限同步失败，不是网络或数据不一致问题。
为什么从库会报权限错误却连不上主库账号？
根本原因：MySQL 主从默认不复制 mysql 库的变更，尤其是旧版本（5.7 及以前）对 GRANT、DROP USER 等操作不写 binlog；即使 8.0+ 默认记录，也常被 replicate_ignore_db=mysql 配置意外屏蔽。
-
SHOW SLAVE STATUS\G中Slave_SQL_Running: No，且Last_SQL_Error明确提示Access denied for user 'repl'@'%' (using password: YES)，说明 SQL 线程在回放一条权限相关语句时失败 - 检查
Replicate_Ignore_DB字段是否含mysql：若为mysql，则所有对mysql.user的修改都不会同步到从库 - 执行
SELECT user,host FROM mysql.user对比主从，从库返回空或缺失复制账号，就是典型表现 - 不要用
INSERT INTO mysql.user手动加账号——它不触发 binlog 写入，也不自动重载权限，从库回放必失败
修复前必须确认的三件事
跳过错误或重配账号前，得先排除环境干扰：
- 确认主库
log_bin已开启：SELECT @@log_bin;返回1，否则任何 DDL/DML 都不会进 binlog - 确认没启用
--skip-grant-tables：运行SELECT @@skip_grant_tables;，结果必须是0，否则权限系统本身已失效 - 确认从库未设
read_only=1且同时禁用了super_read_only：否则GRANT类语句在从库执行会直接报错ERROR 1290
正确修复权限同步中断的实操路径
核心原则：让权限变更真正进入 binlog 并被从库回放，而不是在从库本地硬改。
- 在主库临时关闭 binlog 记录（仅限当前会话）：
SET SESSION sql_log_bin = 0;，再执行DROP USER 'repl'@'%'; CREATE USER 'repl'@'%' IDENTIFIED BY 'xxx'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';，最后SET SESSION sql_log_bin = 1;—— 这样既避免了权限语句污染主库 binlog，又确保从库不会因回放失败而中断 - 如果已中断，先
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，必须用SET GTID_NEXT='xxx-xxx-xxx:nnn'; BEGIN; COMMIT;注入空事务后再启复制 - 修复后立刻验证：
SELECT User,Host,plugin FROM mysql.user WHERE User = 'repl';主从结果应完全一致；再查SHOW SLAVE STATUS\G确认Slave_IO_Running和Slave_SQL_Running均为Yes
最容易被忽略的兼容性细节
权限修复不是“加个用户就完事”，认证插件和密码格式不匹配会导致看似成功、实则无法握手。
- MySQL 8.0+ 默认用
caching_sha2_password插件，但很多中间件或老客户端只支持mysql_native_password；查SELECT plugin FROM mysql.user WHERE User = 'repl';，若不符，需在主库执行：ALTER USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'xxx'; -
FLUSH PRIVILEGES在GRANT后不需要，但在ALTER USER修改 plugin 后建议执行一次，尤其旧版本中该语句不自动刷新内存权限 - 从库若长期延迟，新授权可能尚未生效，可手动执行
FLUSH PRIVILEGES;强制重载（仅限从库本地，不影响主从逻辑）
修复本质不是绕过错误，而是让权限变更以 MySQL 认可的方式进入复制流。任何跳过、硬改、忽略插件兼容性的操作，都会在下次权限变更时再次暴露。
