MySQL同步工具需REPLICATION SLAVE权限（非SELECT或REPLICATION CLIENT），Binlog格式必须为ROW，binlog_row_image须设为FULL，且同步账号还需SELECT权限以支持初始快照。
MySQL 用户必须有 REPLICATION SLAVE 权限
同步工具（如 canal、debezium、maxwell）读取 binlog 本质是伪装成从库，所以不能只给 select 或 replication client。缺 replication slave 会导致连接成功但拉不到事件，日志里常出现 “could not find first log file name in binary log index file” 或直接卡在 waiting for binlog to rotate。
实操建议：
- 用
CREATE USER 'sync_user'@'%' IDENTIFIED BY 'pwd';单独建用户，别复用业务账号 - 执行
GRANT REPLICATION SLAVE ON *.* TO 'sync_user'@'%';—— 注意是ON *.*，不能限定库或表 - 务必执行
FLUSH PRIVILEGES;，否则权限不生效 - 如果 MySQL 8.0+ 启用了
caching_sha2_password插件，客户端可能握手失败，临时改用mysql_native_password：ALTER USER 'sync_user'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd';
Binlog 格式必须设为 ROW
同步工具依赖解析具体行变更，STATEMENT 或 MIXED 格式下，Binlog 里只有 SQL 文本，无法准确还原字段级变化，且容易因函数、时间戳等非确定性操作导致主从不一致。
实操建议：
- 检查当前设置：
SHOW VARIABLES LIKE 'binlog_format';，必须返回ROW - 修改需重启 MySQL 或动态设置（5.7.7+ 支持）：
SET GLOBAL binlog_format = 'ROW'; - 永久生效要写进配置文件：
binlog_format = ROW加到[mysqld]段 - 注意：切换后首次启动会生成新 binlog 文件，旧文件里的非 ROW 日志仍存在，但新同步任务应从新文件开始读
需要开启 binlog_row_image = FULL
默认情况下 MySQL 可能只记录变更后的值（MINIMAL）或主键+变更列（NOBLOB），同步工具若依赖旧值做对比（比如 CDC 场景的 UPDATE 前后镜像），就会丢数据或报错 Unknown column 'xxx' in field list。
实操建议：
- 确认设置：
SHOW VARIABLES LIKE 'binlog_row_image';，必须是FULL - 动态设置：
SET GLOBAL binlog_row_image = 'FULL'; - 配置文件中加：
binlog_row_image = FULL - 该参数不影响性能显著，但影响 Binlog 体积；如果磁盘紧张又确定不需要旧值，才考虑
NOBLOB，但绝大多数同步工具文档明确要求FULL
账号还需 SELECT 权限才能初始化快照
很多同步工具启动时先全量拉一次当前数据（snapshot），再接 Binlog 增量。没 SELECT 权限会卡在 “Fetching snapshot for database xxx” 或报 Access denied for user ... to database 'xxx'，和 Binlog 权限错误混淆。
实操建议：
- 给同步用户加上库级
SELECT：GRANT SELECT ON `target_db`.* TO 'sync_user'@'%'; - 如果要同步多个库，逐个授权，或用
GRANT SELECT ON *.*（不推荐生产环境） - 注意：有些工具（如 Debezium）支持跳过 snapshot，但需显式配置
snapshot.mode=never，此时可不给SELECT，但必须确保 Binlog 位置足够新，否则丢历史变更
最容易被忽略的是 binlog_row_image 和初始快照阶段的 SELECT 权限——前者让增量看起来“正常”，后者让整个流程真正跑通。两者缺一，都可能表现为“连上了但没数据”。
