Canal监听MySQLBinlog配置教程

本文深入解析了使用Canal实现Java应用与MySQL数据同步的关键配置与常见陷阱，直击生产环境中最频发的五大痛点：服务端无法连接MySQL（源于binlog未开启或格式非ROW、账号权限不足）、客户端收不到变更（instance配置与filter正则不匹配）、Java端解析Event失败（误用字段索引、忽略before/after逻辑及主键依赖）、同步延迟或丢数据（batchSize与ack机制配合失当），以及位点不可逆推进风险；通过精准的配置检查命令、授权示例、正则书写规范、代码解析要点和调优建议，为开发者提供了一套开箱即用、避坑高效的实战指南。

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 了，这个位点就再也拿不回来了。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。