canal服务端连不上mysql需满足两个硬性条件：mysql必须开启binlog且格式为row；连接账号需具备replication slave和replication client权限。
Canal 服务端连不上 MySQL：权限和 binlog 格式是硬门槛
Canal 启动后报 ERROR 1236 (HY000) 或日志里反复出现 Lost connection to MySQL server，八成是 MySQL 端没配对。Canal 不是普通客户端，它伪装成从库拉取 binlog，必须满足两个刚性条件：
- MySQL 必须开启
binlog，且格式为ROW（STATEMENT或MIXED会导致 Canal 解析失败或漏事件） - 用于连接的 MySQL 账号需有
REPLICATION SLAVE和REPLICATION CLIENT权限，仅SELECT不够
检查方式：SHOW VARIABLES LIKE 'log_bin'; 和 SHOW VARIABLES LIKE 'binlog_format';；授权语句示例：GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%';
Canal 客户端收不到变更：instance 配置和订阅 filter 没对上
服务端跑着，客户端代码也启了，但 Message 一直为空——问题常出在 Canal 的 instance 层级配置。Canal 不会自动监听所有库表，每个 instance 对应一个逻辑通道，必须显式指定监听目标：
-
canal.instance.filter.regex控制白名单，例如mydb\..*表示只同步mydb下所有表；写成mydb.user才精确匹配单表 - 若 MySQL 表名含大写字母，而 Canal 运行在 Linux 上（默认文件系统不区分大小写），
filter.regex中的大小写必须与SHOW TABLES输出完全一致 - 修改
conf/example/instance.properties后，必须重启对应 instance（sh stop.sh example && sh start.sh example），热加载不生效
Java 客户端解析 Event 失败：RowChange 不等于你想要的 INSERT/UPDATE/DELETE
拿到 Entry 后调用 entry.getStoreValue() 解出 RowChange，却发现 getEventType() 是 UNKNOWN，或者字段值全为 null——这是因为 Canal 默认只传输变更前后的行数据（beforeColumns/afterColumns），不带 SQL 语句，也不保证字段顺序与建表顺序一致：
- 必须遍历
rowChange.getRowDatasList()，每条RowData才对应一次实际 DML；INSERT只有afterColumns，DELETE只有beforeColumns，UPDATE两者都有 - 列名通过
column.getName()获取，不要依赖索引位置；值用column.getValue()，注意isNull()判断，避免 NPE - 如果需要主键值做路由或去重，务必在
filter.regex匹配的表上定义明确主键（Canal 依赖主键生成唯一标识）
同步延迟高或丢数据：batchSize 和 getWithoutAck 的组合很关键
生产环境常见“看着在跑，但下游总差几秒”，甚至偶发跳过某些 binlog 位点——这通常不是网络问题，而是客户端拉取策略没调好：
-
CanalConnector.getWithoutAck(100)的batchSize=100并非每次返回 100 条，而是最多取 100 条未 ACK 的 event；若实际只有 5 条，就只返回 5 条，不会阻塞等待 - 必须手动调用
connector.ack(batchId)，否则下一批拉不到新数据；忘记 ack 或在处理中途 crash，会导致重复消费或卡住 - 高吞吐场景建议把
batchSize设为 50–200，太小（如 1）导致频繁 RPC，太大（如 1000）可能 OOM 或超时；同时检查 MySQL 的max_allowed_packet是否 ≥ Canal 的 batch 单条最大体积
binlog 位点推进靠的是 ack，不是消息处理完成。哪怕解析失败，只要 ack 了，这个位点就再也拿不回来了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
