Canal 部署的三步
Canal Server 部署分三步：解压发布包、编辑 conf/canal.properties（serverMode 与 destinations 列表）、编辑 conf/<destination>/instance.properties（数据源与过滤规则）。实例配置里 master 地址、账号、slaveId、filter.regex 是要按环境调整的项；启动后看 logs 目录确认连接与位点是否正常，日志会明确写出当前拉到哪个 binlog 文件与位点。
基本信息
| canal.properties | 定义 serverMode 与 destinations 列表 |
|---|---|
| instance.properties | 每个 destination 一份，含数据源与过滤规则 |
| meta.dat | 记录该 destination 的消费位点，不能手工删除 |
| filter.regex | 按 Java 正则匹配 库.表，多个用逗号分隔 |
典型使用场景
- 首次部署：配置数据源与过滤规则并验证连接
- 新增同步库表：新增 destination 或调整 filter.regex
- 位点丢失：meta.dat 被删后只能重做初始化
- 多实例部署：为每个实例分配不同的 slaveId
- 故障排查：通过日志确认连接、拉取与位点推进情况
instance.properties 关键项
instance.properties 关键项
# 示例 destination：example
canal.instance.master.address=10.0.0.5:3306 # 源库地址
canal.instance.dbUsername=canal # 同步账号，需要 replication 相关权限
canal.instance.dbPassword=*** # 密码不要提交到代码仓库
canal.instance.mysql.slaveId=1234 # 模拟从库 ID，多实例必须唯一
canal.instance.filter.regex=app\..* # 只同步 app 库下的表
canal.instance.connectionCharset=UTF-8
canal.instance.gtidon=false # 是否按 GTID 模式解析配置文件与作用
| 文件 | 内容 | 注意点 |
|---|---|---|
| canal.properties | serverMode、destinations | 多个 destination 用逗号分隔 |
| instance.properties | 数据源、账号、slaveId、过滤规则 | 按 destination 目录区分 |
| meta.dat | 消费位点记录 | 删除后位点丢失，需要重新初始化 |
| logs 目录 | 运行日志 | 排查连接与位点推进的第一现场 |
改完配置需要重启 Canal Server 才生效；不要多个实例复用同一个 slaveId，否则源库侧会互相踢掉对方的复制连接。
filter.regex 用 Java 正则匹配「库名.表名」，转义写错时过滤范围会与预期完全不同：要么漏同步，要么把不该同步的库也拉进来，配好后先用小表验证一次。
上线前后的检查清单
部署完成后按顺序确认四件事：一是源库已开启 binlog 且格式为 ROW（Canal 依赖行模式解析）；二是同步账号具备复制相关权限；三是日志里能看到连接成功与位点开始推进；四是下游确实收到了消息。前三项都能在 logs 目录里找到证据，第四项要实际消费一次验证。位点开始推进后建议观察一段时间再交付，避免出现「连上了但一直不推进」的隐性故障。