canal启动失败主因是权限不足与配置错误：需创建专用用户并授予replication slave、replication client及select权限，binlog必须启用且格式为row，server_id不可与canal slaveid冲突。
Canal 必须以 MySQL 从库身份连接并拉取 binlog，所以不是“给 Canal 配权限”，而是创建一个具备 REPLICATION SLAVE 和 REPLICATION CLIENT 权限的专用 MySQL 用户——这是 Canal 启动失败最常见的权限原因。
检查 binlog 是否已启用且格式为 ROW
Canal 依赖 binlog 存在且内容可解析，否则连连接都进不去解析环节：
-
SHOW VARIABLES LIKE 'log_bin';必须返回ON，否则 Canal 启动时会报错ERROR c.a.o.c.c.i.CanalInstanceWithSpring - start CannalInstance for 1 failed，日志里紧跟着提示Failed to find the master log file -
SHOW VARIABLES LIKE 'binlog_format';必须是ROW；STATEMENT或MIXED下 Canal 虽能启动，但 UPDATE/DELETE 事件可能缺失主键或旧值，导致下游无法准确识别变更行 - 如果 MySQL 是阿里云 RDS，默认已开 binlog 且格式为 ROW，跳过配置，但权限仍需显式授予（RDS 不允许直接
GRANT给新用户，需通过控制台添加高权限账号）
创建 Canal 专用用户并授予权限
不能复用 root 或业务账号，必须新建用户并最小化授权：
- MySQL 8.0+：执行
CREATE USER 'canal'@'%' IDENTIFIED BY 'your_strong_password'; - MySQL 5.7：用
CREATE USER 'canal'@'%' IDENTIFIED WITH mysql_native_password BY 'your_strong_password';（否则可能因默认 auth plugin 不兼容导致连接被拒） - 统一执行授权：
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%';—— 注意SELECT是必需的，Canal 初始化时会查information_schema获取表结构 - 立即执行
FLUSH PRIVILEGES;，否则权限不生效，Canal 连接时抛出Access denied; you need (at least one of) the SUPER, REPLICATION SLAVE privilege(s)
验证用户能否真正读取 binlog
光看 SHOW GRANTS 不够，要模拟 Canal 行为走通最小链路：
- 用该用户登录：
mysql -u canal -p -h your_mysql_host，确认能连上 - 执行
SHOW MASTER STATUS;，应返回当前 binlog 文件名和 position；若报错ERROR 1227 (42501): Access denied; you need ... REPLICATION CLIENT，说明REPLICATION CLIENT没授全 - 执行
SHOW BINLOG EVENTS IN 'mysql-bin.000001' LIMIT 1;（替换为实际文件名），能查出 event 就代表REPLICATION SLAVE生效；若报错ERROR 1227 (42501): Access denied; you need ... REPLICATION SLAVE，说明权限未落库或没FLUSH PRIVILEGES
server_id 冲突会导致 Canal 同步卡死
Canal 实例启动时会向 MySQL 注册一个 slaveId（默认 1234），而 MySQL 的 server_id 必须与之不同，否则 MySQL 主动断连：
- 检查 MySQL 当前
server_id：SHOW VARIABLES LIKE 'server_id'; - 若返回
1，则 Canal 的instance.properties中必须改掉canal.instance.mysql.slaveId，比如设为1235；否则 Canal 日志反复打印com.alibaba.otter.canal.parse.inbound.mysql.dbsync.DirectLogFetcher: Exiting...，无任何错误提示，极难定位 - 注意：多个 Canal 实例不能共用同一个
slaveId，否则后启动的会把先启动的踢下线
最容易被忽略的是 SELECT 权限和 server_id 冲突——前者让 Canal 连不上，后者让它连上了却收不到任何 event，现象都是“静默失败”。务必逐条验证，别只信 SHOW GRANTS 的输出。
