MySQL主从复制默认不同步mysql系统库，因权限操作在ROW模式下被replicate-ignore-db=mysql跳过，或STATEMENT模式下被过滤；必须用CREATE USER/GRANT语句并校验版本兼容性。
主从复制默认不同步 mysql 系统库
MySQL 主从复制默认只同步 binlog_format=ROW 或 STATEMENT 下的 DML 和部分 DDL，但 mysql 库（含 user、db、tables_priv 等权限表）的变更不会自动复制过去——哪怕你执行了 GRANT 或 CREATE USER。这是因为权限操作底层常转为对系统表的 INSERT/UPDATE，而这些语句在 binlog_format=STATEMENT 下可能被过滤，在 ROW 模式下又因系统库默认被 replicate-ignore-db=mysql 类配置跳过。
- 检查你的从库是否启用了
replicate-ignore-db=mysql（常见于旧版部署脚本），这是最常被忽略的配置项 -
GRANT语句本身会被记录进 binlog，但仅当binlog_format=STATEMENT且未显式禁用系统库复制时才有效；ROW模式下它不生成对应事件 - 即使开启系统库复制，
mysql.user表的password_expired、account_locked等字段在 5.7+ 中由服务端直接维护，不走 SQL 接口，无法被 binlog 捕获
用 CREATE USER + GRANT 替代直接改表
有人习惯手动 UPDATE mysql.user 或 INSERT INTO mysql.db 来加权限，这在集群中极危险：从库可能因表结构差异、字符集不一致或触发器缺失导致同步中断，且这类操作完全绕过 binlog 记录逻辑，主从权限必然分裂。
- 必须统一使用
CREATE USER和GRANT语句（不是INSERT或UPDATE），它们能正确生成 binlog 事件 - 5.7+ 中
GRANT若涉及新用户，会隐式创建，但建议拆成两步：先CREATE USER（带IDENTIFIED BY），再GRANT，避免因密码策略不同导致从库报错ERROR 1827 (HY000) - 所有权限语句需在主库执行，严禁在从库执行（哪怕
SET sql_log_bin=0临时关闭），否则后续主库同名用户变更会冲突
GTID 模式下权限变更的兼容性陷阱
启用 GTID 后，权限同步看似更可靠，但实际存在两个隐藏问题：一是 CREATE USER 在 GTID 中被标记为“事务性”，但如果主库执行时发生回滚（如密码不符合策略），从库可能已应用部分事件；二是 MySQL 8.0 的角色（ROLE）和动态权限（如 BACKUP_ADMIN）在低版本从库上无法识别，会直接报错 ERROR 3528 (HY000) 中断复制。
- 确认所有节点 MySQL 版本一致，尤其升级后要检查从库是否支持主库使用的权限类型
- 避免在 GTID 集群中混用
FLUSH PRIVILEGES——它不写 binlog，且在从库执行无意义，还可能掩盖真实权限未同步的问题 - 若必须支持跨版本，权限变更前先在从库执行
SELECT VERSION()和SHOW VARIABLES LIKE 'version%'校验兼容性
定期校验权限一致性比依赖自动同步更可靠
无论配置多严谨，权限数据在高可用集群中始终是弱一致性状态。网络延迟、复制延迟、人为误操作都可能导致某台从库权限滞后数分钟甚至数小时，而应用连接池往往随机选节点，这就造成“同一账号在不同节点权限不同”的诡异问题。
- 用脚本定期比对主从
SELECT user,host,authentication_string FROM mysql.user的 MD5 值，比全量导出更快更轻量 - 不要只查
mysql.user，还要覆盖mysql.db、mysql.tables_priv和 8.0+ 的mysql.role_edges，遗漏任一表都可能漏掉关键权限 - 校验脚本最好带自动修复选项（如生成缺失的
GRANT语句），但修复动作必须人工确认后再执行，避免误覆盖
权限不是普通业务数据，它没有“最终一致性”的容错空间。一次 REVOKE 没同步，就可能让某个关键服务连不上数据库；一次 CREATE USER 被跳过，监控告警就收不到通知。所以别太信配置，多跑几遍校验脚本，比调三天复制参数实在。
