Canal客户端连不上mysql需检查binlog_format=ROW、用户权限（select/REPLICATION SLAVE/CLIENT）、server_id唯一性及docker配置生效；destination与instance配置须严格匹配；解析Event失败多因字段映射或DDL未同步；flink CDC在全量同步、语言生态、ack机制等方面尚不能完全替代Canal。
Canal 客户端连不上 MySQL：检查 binlog 格式和权限
Canal 无法启动消费，常见原因是 MySQL 没开 ROW 格式的 binlog，或 Canal 用户缺少必要权限。
-
binlog_format必须设为ROW（不能是MIXED或STATEMENT），否则 Canal 解析不到行级变更 - MySQL 用户需有
SELECT、REPLICATION SLAVE、REPLICATION CLIENT权限，缺一不可 - 确认
server_id已设置且全局唯一，否则 Canal 会报Error 1236类同步位点错误 - 如果用 Docker 部署 MySQL，注意
my.cnf是否被挂载覆盖，配置可能没生效
Canal Server 启动后无数据：确认 destination 和 instance 配置匹配
Canal Server 起来了，但客户端收不到任何事件，大概率是 destination 名称不一致或 instance 未启用。
- 客户端连接时指定的
destination（如example）必须与 Canal Server 的conf/example/instance.properties文件名完全一致 -
conf/canal.properties中的canal.destinations要包含该 destination，否则 instance 不加载 - 检查
instance.properties中canal.instance.master.address是否指向真实 MySQL 地址+端口（别写成localhost） - 日志里搜
start successful，没这句说明 instance 没起来；搜parse start确认 binlog 解析线程是否运行
消费端解析 Event 失败：字段类型映射和 DDL 变更处理
Canal 发送的 Entry 在下游解析时报空指针或类型转换异常，通常是字段缺失、DDL 未同步或时间类型处理不当。
- 表结构变更（如新增列）后，旧客户端未重启，
column列表长度与预期不符，建议用column.getName()+column.getValue()安全取值，别依赖下标 - MySQL 的
timestamp/DATETIME在 Canal 中默认转成字符串，若下游用Long接收会抛NumberFormatException - 遇到
ALTER table事件，EventType.QUERY类型的 Entry 不带RowData，直接跳过或记录日志，别硬解 - 若开启
canal.instance.Filter.Regex，正则写错会导致整张表被过滤掉，建议先用.*..*全量测试再收敛
Flink CDC 替代 Canal？别急着换，先看场景边界
有人一遇到 Canal 维护成本高就想切 Flink CDC，但实际生产中 Canal 仍有不可替代性。
- Flink CDC 0.4+ 支持 MySQL
SCAN+CHANGELOG，但首次全量同步期间无法保证 Exactly-Once（依赖 checkpoint 机制，非 binlog 位点） - Canal 输出的是标准 binlog event 流，可直连 kafka/Pulsar，下游用任意语言消费；Flink CDC 强绑定 Flink 运行时
- Canal 支持
client ack机制，能控制消费进度；Flink CDC 的 offset 提交粒度在 checkpoint，延迟更高 - 如果数仓 etl 需要按业务规则做轻量过滤（比如只取某几个字段）、或对接非 Java 系统（如 Python 流计算），Canal 的协议裸输出更可控
Canal 的坑不在协议本身，而在 MySQL 配置漂移、网络抖动导致的位点错乱——每次上线前务必用 show master status 对齐初始位点，别信 Canal 自动回溯逻辑。