根本原因是MySQL原生复制硬编码跳过mysql库的DML/DDL操作，即使主库执行GRANT或CREATE USER，binlog中也不会生成对应事件，导致从库无法同步。
为什么直接执行 GRANT 不会同步到从库或集群其他节点
MySQL 原生复制（包括 GTID 和基于行的复制）默认跳过 mysql 库的所有 DML/DDL 操作，这是硬编码逻辑，不是靠配置能打开的。哪怕你在主库执行了 CREATE USER 'app'@'10.20.%' IDENTIFIED BY 'p'，这条语句在 binlog_format=ROW 下不会生成对应事件；在 STATEMENT 模式下，又常因 replicate-ignore-db=mysql 被过滤。结果就是：主库上查得到用户，从库或集群其他节点上 SELECT * FROM mysql.user 查不到，连接直接报 Access denied。
密码变更必须分两步：先改主库账号，再手动更新从库复制配置
主从复制依赖一个专用账号（如 'repl'@'192.168.%'），它的密码变更不能只在主库用 ALTER USER —— 从库仍用旧密码连主库，IO 线程会卡住，报错类似 ERROR 12154 或认证失败。
- 先在主库执行：
ALTER USER 'repl'@'192.168.%' IDENTIFIED BY 'new_pass_2026'; FLUSH PRIVILEGES; - 再到从库停复制：
STOP SLAVE; - 更新连接参数（注意保持
MASTER_LOG_FILE和MASTER_LOG_POS不变）：CHANGE MASTER TO MASTER_PASSWORD='new_pass_2026'; - 重启：
START SLAVE;，然后SHOW SLAVE STATUS\G确认Slave_IO_Running和Slave_SQL_Running都是Yes
漏掉任何一步，复制就断了。特别注意：不要在从库执行 UPDATE mysql.user 改密码 —— read_only=1 会拒绝写入，且绕过 binlog，导致后续主库同名用户变更冲突。
同步普通业务账号权限，必须用幂等 SQL + 逐节点执行
没有“一键同步账号”的安全方案。你得在所有节点上跑相同语句，但要防重复、防失败、防版本不兼容。
- 用
CREATE USER IF NOT EXISTS+GRANT ... WITH GRANT OPTION组合，避免某节点已存在用户时整个脚本中断 - MySQL 8.0+ 中，
authentication_plugin必须一致：如果主库用caching_sha2_password，从库也得是，否则即使账号存在也会认证失败；检查用SELECT plugin FROM mysql.user WHERE user = 'dev_app'; - 角色（ROLE）不能靠复制同步：
CREATE ROLE 'app_reader'; GRANT SELECT ON mydb.* TO 'app_reader';必须在每个节点单独执行；再用GRANT 'app_reader' TO 'dev_user'@'%'; SET DEFAULT ROLE 'app_reader' TO 'dev_user'@'%';补全 - 别信
FLUSH PRIVILEGES：它不写 binlog，在从库执行无意义，还可能掩盖权限没真正同步的问题
用 pt-show-grants 导出再重放是最少出错的实操路径
手写 SQL 容易漏列级权限、SSL 选项、资源限制或角色绑定。pt-show-grants（Percona Toolkit）能自动提取完整权限上下文，比 SHOW GRANTS 更可靠。
- 从主库导出：
pt-show-grants --host=master_ip --user=root --password=xxx --no-create-user > grants.sql - 导入前，先在从库关 binlog：
SET SQL_LOG_BIN=0;，防止循环写入 - 执行：
mysql - 验证是否生效：不只是看 SQL 执行成功，还要在每台节点跑
mysql -u dev_user -h $ip -e "SELECT 1" 2>/dev/null || echo "FAIL on $ip"
真正难的不是怎么同步，而是谁来触发、何时触发、有没有人核对所有节点的 SHOW GRANTS FOR 'dev_user'@'%' 输出是否完全一致——空格、换行、大小写都得对得上。
