Canal仅支持binlog_format=ROW模式，必须配置log-bin、binlog-format=ROW和合法server_id并重启MySQL验证；canal-adapter官方仅稳定支持ES 6.8.x，7.x+不兼容；filter.regex需用Java正则如shop..*匹配库表。
Canal 本身不直接写入 Elasticsearch，必须通过 canal-adapter 中转；跳过 adapter 直接用 client 自研推送，开发成本高、容错弱，不推荐。
MySQL 必须开启 ROW 格式 binlog 且配置合法 server_id
Canal 依赖 MySQL 的 binlog 流，但只支持 binlog_format=ROW。如果设为 STATEMENT 或 MIXED，canal-server 启动后会报错：Unsupported binlog format，日志里还可能夹带 parse failed。
- 在
my.cnf的[mysqld]段落中确认三行都存在且无注释：log-bin=mysql-bin、binlog-format=ROW、server_id=123（值不能为 0 或重复） -
server_id要和canal.instance.mysql.slaveId区分开——后者是 Canal 假装的 slave 编号，前者是 MySQL 自身复制体系的身份标识 - 改完配置需重启 MySQL，并用
SHOW VARIABLES LIKE 'binlog_format';和SHOW MASTER STATUS;双重验证
canal-adapter 的 es6+ 兼容性陷阱：别碰 7.x 以上版本
截至 2026 年 4 月，canal-adapter 官方稳定支持仅到 Elasticsearch 6.8.x；对接 7.x 或 8.x 会出现 java.lang.NoClassDefFoundError: org/elasticsearch/action/bulk/BulkProcessor$Builder 类缺失错误，本质是 ES Java Client API 不兼容。
- 若你用的是阿里云 ES Serverless 或托管版 7.x+，不要硬上 canal-adapter；改用
logstash-input-jdbc（适合低频）或自研 Flink CDC + REST Bulk 写入（适合高频） - 本地测试可降级到 ES 6.8.23，对应 JDK 8u202+，并确保
application.yml中esAddress写成http://localhost:9200，不能带/_search等路径 -
canal-adapter的esMapping配置里，_id字段必须显式映射为pk或sql，否则 UPDATE/DELETE 无法定位文档
instance.properties 的 filter.regex 写错会导致“看起来同步了，其实没数据”
很多人配完启动没报错，ES 里却空空如也，问题常出在 canal.instance.filter.regex。它不是 SQL WHERE 条件，而是 Java 正则，且匹配目标是 database.table 全名。
- 想同步
shop库下所有表，要写shop\..*，不是shop.*（少一个反斜杠，正则就失效） - 同步多个库用竖线分隔：
shop\..*|user\..*；注意竖线是正则“或”，不是 shell 管道符 - 误写成
.*看似保险，但 Canal 会尝试监听所有库（包括mysql系统库），触发权限不足报错：Access denied; you need (at least one of) the SUPER or SLAVE privileges - 调试时可在
canal-server日志中 grepdestination:和filter:，确认实际生效的正则是否符合预期
真正卡住人的往往不是启动失败，而是“没报错但没数据”——这时优先查 filter.regex 是否匹配、esMapping._id 是否可定位、ES 版本是否被官方支持。Canal 的可靠在于 binlog 解析，脆弱点永远在上下游衔接处。
