📚 课程目录第4章 Canal环境搭建

4. Canal 环境搭建：从下载到验证

好，咱们进入实战环节。Canal 的安装其实不复杂，但有几个细节容易踩坑。我刚开始接触时也折腾了半天，后来才发现是配置文件的编码问题。今天我把完整的流程拆开讲，你跟着做就行。

4.1 下载与安装

Canal 官方提供了两种部署方式：直接下载压缩包，或者用 Docker。我个人习惯用压缩包，因为能更清楚地看到每个配置文件的用途。

第一步：确认环境

Canal 依赖 Java 8 以上版本，MySQL 需要开启 Binlog。嗯，这两点缺一不可。你可以先跑一下命令检查：

# 检查 Java 版本
java -version

# 检查 MySQL 是否开启 Binlog
SHOW VARIABLES LIKE 'log_bin';

如果 log_bin 是 OFF，那得先去 MySQL 配置文件里打开。我在项目中遇到过好几次，部署前没检查，结果启动 Canal 后一直报错找不到 Binlog 文件。

第二步：下载 Canal

去 GitHub Releases 页面下载 canal.deployer-1.1.6.tar.gz（版本号以实际为准）。解压到指定目录：

mkdir -p /opt/canal
tar -xzf canal.deployer-1.1.6.tar.gz -C /opt/canal

解压后的目录结构是这样的：

目录/文件	说明
bin/	启动和关闭脚本
conf/	配置文件目录（核心）
lib/	依赖的 JAR 包
logs/	运行日志（排错时必看）

小提示： 我建议把 Canal 放在独立的用户下运行，别用 root。曾经有个同事用 root 启动，结果日志文件权限混乱，排查了半天。

4.2 核心配置：canal.properties

这个文件是 Canal 服务端的全局配置。说白了，它决定了 Canal 作为一个服务怎么跑。打开 conf/canal.properties，重点关注这几个参数：

# Canal 服务端口
canal.port = 11111

# 注册到 Zookeeper 的地址（如果用了集群）
canal.zkServers = 127.0.0.1:2181

# 实例模式：tcp（直连）、kafka、rocketmq
canal.serverMode = tcp

# 实例数量（默认 1 个）
canal.destinations = example

这里有个坑：canal.destinations 的值必须和 conf/ 目录下的实例文件夹名称一致。比如你写 example，那 conf/ 下就得有 example/ 这个目录。我刚开始就写错了，结果启动时一直报 instance not found。

注意： 如果 canal.serverMode 设置为 kafka 或 rocketmq，还需要额外配置 MQ 的连接信息。这部分我们后面章节会细讲，今天先以 tcp 模式为例。

4.3 实例配置：instance.properties

每个 Canal 实例对应一个 MySQL 数据源。配置文件在 conf/example/instance.properties。这是最关键的配置，我逐行解释：

# MySQL 主库地址
canal.instance.master.address = 127.0.0.1:3306

# Binlog 解析位置（首次启动可以不填）
canal.instance.master.journal.name = 
canal.instance.master.position = 

# 数据库账号（必须有 REPLICATION 权限）
canal.instance.dbUsername = canal
canal.instance.dbPassword = canal

# 需要监听的数据库和表
canal.instance.filter.regex = .*\\..*
# 格式：库名\\.表名，多个用逗号隔开
# 例如：test\\.user,test\\.order

权限问题要特别留意。 我曾经在客户现场部署时，DBA 给的账号只有 SELECT 权限，结果 Canal 连不上。正确的授权语句是：

CREATE USER 'canal'@'%' IDENTIFIED BY 'canal';
GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%';
FLUSH PRIVILEGES;

你想想看，如果没有 REPLICATION SLAVE 权限，Canal 根本读不到 Binlog 流。这个坑我踩过，所以每次部署都会先确认权限。

4.4 启动与验证

配置写好了，咱们启动试试。进入 Canal 的 bin/ 目录：

# 启动
./startup.sh

# 查看日志
tail -f ../logs/canal/canal.log

如果看到类似这样的输出，说明启动成功：

2024-01-15 10:30:00.123 [main] INFO  c.a.o.c.CanalLauncher - ## start the canal server successfully.
2024-01-15 10:30:01.456 [main] INFO  c.a.o.c.CanalLauncher - ## the canal server is running now ......

接着验证实例是否正常：

# 查看实例日志
tail -f ../logs/example/example.log

正常情况会输出：

2024-01-15 10:30:05.789 [destination = example] INFO  c.a.o.c.i.core.CanalInstance - start CanalInstance for 1-example
2024-01-15 10:30:06.012 [destination = example] INFO  c.a.o.c.i.p.a.AuthenticationInfo - connect to 127.0.0.1:3306 success

看到 connect success 就稳了。如果报错，八成是网络不通、账号权限不对，或者 Binlog 没开启。

  验证小技巧： 在 MySQL 里执行一条 INSERT 语句，然后看 Canal 的日志。如果出现 received binlog event 字样，说明数据已经成功捕获到了。

4.5 整体架构回顾

为了让你更直观地理解 Canal 的组件关系，我画了一张图：

从图上你能看到：Canal Server 是总管，负责加载全局配置；每个 Instance 对应一个 MySQL 数据源，独立运行；客户端通过 TCP 直连 Canal Server 获取数据。这种架构的好处是——一个 Canal 服务可以同时监听多个数据库，互不干扰。

4.6 常见问题速查

最后，我把部署过程中最容易遇到的问题整理成表格，方便你对照排查：

现象	原因	解决方法
启动后立即退出	Java 版本过低或端口被占用	检查 Java 版本，用 `netstat -tlnp` 查看 11111 端口
连接 MySQL 失败	账号权限不足或网络不通	确认 REPLICATION 权限，检查防火墙
收不到 Binlog 事件	过滤规则写错或 Binlog 格式不对	检查 `filter.regex`，确认 MySQL 的 Binlog 格式为 ROW
日志乱码	配置文件编码不是 UTF-8	用 `file -i` 检查编码，统一改为 UTF-8

我的习惯： 每次部署完，我都会在 MySQL 里执行一条 SHOW MASTER STATUS，记下当前的 Binlog 文件名和位置。万一 Canal 需要重新初始化，这个信息能救命。

好了，Canal 的环境搭建就到这里。配置文件的每个参数我都解释过了，你按步骤操作应该不会出大问题。如果遇到奇怪的现象，先看日志，日志里通常有明确的错误信息。