同步工具必需REPLICATION SLAVE和REPLICATION CLIENT权限，缺一不可，且须显式授予ON .；BINLOG MONITOR与同步无关，误授反致ERROR 3715。
普通用户不能也不该被授予 BINLOG MONITOR 权限——它和同步工具完全无关，加了反而报错。真正需要的是 REPLICATION SLAVE 和 REPLICATION CLIENT 这两个权限，缺一不可，且必须显式授予到 ON *.* 级别。
为什么 BINLOG MONITOR 是个干扰项？
这个权限是 MySQL 8.0.22+ 引入的内部监控权限，只供 replica 线程自身调用 SHOW BINLOG EVENTS 等管理命令，同步工具（如 canal、debezium）压根不走这条路。误授会触发 ERROR 3715 (HY000): Access denied; you need (at least one of) the BINLOG MONITOR privilege(s)，但问题根源其实是漏了 REPLICATION CLIENT 或 REPLICATION SLAVE。
常见误操作包括：
- 只执行
GRANT REPLICATION SLAVE ON *.* TO 'sync_user'@'%'，忘了REPLICATION CLIENT - 在 MySQL 5.7 上强行授
BINLOG MONITOR，结果提示Unknown privilege - 把
BINLOG_ADMIN（用于人工查日志）和同步权限混为一谈
同步工具真正依赖的两个权限怎么配？
必须同时授予，且作用域只能是全局：ON *.*，不能限定库或表。
正确写法：
CREATE USER 'sync_user'@'%' IDENTIFIED BY 'pwd'; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'sync_user'@'%'; FLUSH PRIVILEGES;
注意点：
- MySQL 8.0+ 若启用了
caching_sha2_password插件，客户端可能握手失败，需补一句：ALTER USER 'sync_user'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd'; - 权限改完不执行
FLUSH PRIVILEGES;，新权限不会生效 - 只给
REPLICATION CLIENT会导致工具无法连接 binlog stream；只给REPLICATION SLAVE会导致拿不到当前File和Position，启动卡住
为什么还要额外加 SELECT 权限？
多数同步工具（如 debezium、canal）启动时会先做一次全量快照（snapshot），从各表 SELECT * 拉取当前数据，再接 binlog 增量。没 SELECT 权限，会卡在 Fetching snapshot for data... 或报 Access denied for SELECT。
如果主库开了 GTID，部分工具还会查 performance_schema.replication_applier_status_by_coordinator，这也依赖 SELECT 权限。
所以最终最小权限集是：
REPLICATION SLAVEREPLICATION CLIENT-
SELECT（必须覆盖要同步的所有库表，建议ON *.*或至少ON target_db.*）
最容易被忽略的 Binlog 配置联动项
权限只是基础，MySQL 服务端配置不匹配，照样同步失败。重点检查三项：
-
binlog_format必须为ROW（SHOW VARIABLES LIKE 'binlog_format';返回ROW），MIXED或STATEMENT下工具无法解析字段级变更 -
binlog_row_image必须为FULL（SHOW VARIABLES LIKE 'binlog_row_image';），否则 UPDATE 前后镜像缺失，CDC 场景直接丢数据 -
server_id必须非零且唯一（SHOW VARIABLES LIKE 'server_id';），否则同步工具连接后无法注册为合法 slave
这三项和权限一样，缺一不可；改了 binlog_format 或 binlog_row_image 后，记得确认新 binlog 文件已生成（SHOW BINARY LOGS;），同步任务必须从新文件开始读，旧文件里的非 ROW 日志无效。
