如何修复MySQL由于权限配置错误导致的从库同步中断？-mysql教程-PHP中文网

SHOW SLAVE STATUS\G 是排查主从权限同步失败的唯一入口，重点检查 Last_SQL_Error 是否含 Access denied 等权限错误，并确认 mysql 库未被 replicate_ignore_db 屏蔽、主库 binlog 已开启、无 --skip-grant-tables 及 read_only 干扰。

如何修复mysql由于权限配置错误导致的从库同步中断？

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 并被从库回放，而不是在从库本地硬改。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

在主库临时关闭 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 认可的方式进入复制流。任何跳过、硬改、忽略插件兼容性的操作，都会在下次权限变更时再次暴露。