canal客户端连接失败主因是tcp握手或认证配置错误；需正确设置mysql账号权限、手动处理auth流程或换用支持auth的客户端库，并通过tcpdump验证authswitchrequest包。
Canal 客户端连接失败：常见 handshake 错误和认证配置
Go 项目连不上 Canal server，十有八九卡在 TCP 握手或身份校验阶段。Canal 默认启用 auth，但 Go 客户端库（如 github.com/go-mysql-org/go-mysql/canal）不自带 auth 协议支持，必须手动处理登录流程。
实操建议：
- 确认 Canal server 配置中
canal.instance.dbUsername和canal.instance.dbPassword已设为 MySQL 实际账号（该账号需有REPLICATION SLAVE权限） - Go 客户端启动时不能直接传 MySQL 账号密码；要改用 Canal 的
GetBinlogDumpCommand+ 自定义握手逻辑，或换用更轻量的github.com/ruiaylin/binlog（它封装了 Canal 协议 auth 流程） - 抓包验证：用
tcpdump -i lo port 11111看是否收到 Canal 的AuthSwitchRequest包，若无响应，说明 Canal server 未启用 auth 或端口不对（默认 11111）
解析 Binlog event 时字段为空或类型错乱
MySQL 5.7+ 开启 binlog_row_image=FULL 是前提，否则 RowEvent 中的 BeforeColumns/AfterColumns 可能缺失。Go 客户端解析时若没按 column count 对齐 schema，event.GetTable() 返回空、event.Rows 解析出错都是必然结果。
实操建议：
- 检查 MySQL 配置：运行
SHOW VARIABLES LIKE 'binlog_row_image';，确保值为FULL - 在 Canal instance 配置里显式设置
canal.instance.filter.regex=.*\..*，避免因表过滤导致 schema 同步失败 - Go 侧必须调用
canal.GetTableMeta(event.Header.LogPos)获取实时表结构，不能硬编码 column index；尤其注意TINYINT(1)在 Go 中常被误读为bool，实际应转int8
同步延迟高且 CPU 持续 100%：事件积压与反序列化瓶颈
Canal 发送的是压缩后的 RowEvent protobuf 数据，Go 客户端若每条 event 都新建 proto.Unmarshal 实例、反复分配 slice，会触发频繁 GC；同时未做并发消费控制，单 goroutine 处理不过来就堆积在 channel 缓冲区。
实操建议：
- 复用
proto.Buffer：初始化一个全局var pbBuf = proto.NewBuffer(nil)，每次pbBuf.SetBuf(data)+pbBuf.Unmarshal(&event) - 消费层加 worker pool：用
chan *canal.Entry接收原始 event，再分发给固定数量 goroutine 处理，避免阻塞 Canal client 的网络读循环 - 关闭 Canal 的
canal.instance.memory.buffer.memunit（默认 1024），改小为 512，降低单次拉取量，换取响应及时性
DDL 语句丢失或无法识别：Canal 过滤规则与 Go 事件类型判断
Canal 默认把 DDL 封装成 QueryEvent，但 Go 客户端库常只监听 RowEvent 类型，导致 CREATE TABLE、ALTER TABLE 完全被忽略。另外，canal.instance.filter.black.regex 若配了 mysql\..*，可能意外过滤掉 mysql.general_log 这类系统表的 DDL。
实操建议：
- Go 代码中必须同时注册
OnRow和OnStatement回调，后者专门处理QueryEvent - 解析
QueryEvent时，不要依赖event.Sql字段直接执行——它可能含注释或跨行，要用sqlparser库（如vitess.io/vitess/go/sqlparser）提取真实操作类型 - Canal instance 配置里禁用
canal.instance.filter.black.regex，改用白名单canal.instance.filter.regex显式列出要同步的库表
真正麻烦的不是连上 Canal，而是 schema 变更时如何让 Go 端自动重建 column mapping。这需要把 TableMeta 缓存起来，并监听 QueryEvent 中的 DDL，再原子更新内存中的 map[string]*schema.Table。没人帮你做这件事，得自己写。
