MySQL分布式集群无法自动同步用户权限，因其原生机制硬编码跳过mysql库复制；GRANT/CREATE USER不写入binlog，Group Replication中mysql库完全不参与组通信；需用pt-show-grants加--no-create-user等参数生成完整语句，并通过SHOW GRANTS、role_edges查询及真实连接验证各节点权限一致性。
MySQL分布式集群中无法自动同步用户权限——这不是配置遗漏或脚本没写对，而是 MySQL 原生机制硬编码跳过 mysql 库的复制，所有“自动同步”尝试都会在某个节点上静默失败或报 Access denied。
为什么 GRANT 和 CREATE USER 不会进 binlog
无论你用的是 GTID 还是 ROW 复制模式，mysql 库的 DML/DDL 操作（包括 CREATE USER、GRANT、DROP ROLE）默认被 SQL 线程跳过。这不是靠改 replicate-do-db 就能打开的功能。
-
binlog_format=ROW下：权限变更不生成事件，因为系统表写入绕过 binlog 接口 -
binlog_format=STATEMENT下：语句可能因上下文缺失（如密码策略、plugin 不一致）在从库执行失败，报ERROR 1827或ERROR 3528 - Group Replication 更彻底：
mysql库完全不参与组通信，连事务广播都不发
用 pt-show-grants 生成可重放语句，但必须加参数
Percona Toolkit 的 pt-show-grants 是目前最接近“自动化”的工具，但它默认输出不完整，直接执行会漏掉关键信息。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 必须加
--no-create-user：避免目标节点已有用户时报错中断 - 列级权限要显式加
--columns，否则GRANT SELECT(col1)类语句不会出现 - 角色绑定需配合
--roles，否则GRANT 'app_reader' TO 'dev_user'@'%'会被忽略 - 执行前先在源库确认
performance_schema已启用，否则动态权限（如BACKUP_ADMIN）查不到
Ansible 同步时必须验证三件事，缺一不可
哪怕你用 mysql_query 模块跑完所有 GRANT，也不能认为权限已生效——MySQL 返回 “Query OK” 只代表语法通过，不代表账号真能连、权限真能用。
- 在每台目标实例上运行
SHOW GRANTS FOR 'dev_app'@'192.168.10.%'，比对输出是否**逐字符一致**（注意空格、换行、大小写） - 查
mysql.role_edges表确认角色继承关系已写入：SELECT COUNT(*) FROM mysql.role_edges WHERE TO_USER = 'dev_app' - 用测试账号真实连接一次：
mysql -u dev_app -h $ip -P3306 -e "SELECT 1" 2>/dev/null || echo "FAIL on $ip"
真正难的不是生成 SQL 或写 playbook，而是每次权限变更都要明确回答：这个账号是否必须在所有节点上 **同时存在、plugin 完全一致、角色默认启用、且 read_only=1 下仍可登录**——这些条件只要一个不满足，就不是“同步失败”，而是“权限模型已分裂”。
