Canal 数据同步服务
阿里 Canal 的 server 默认端口：Canal 伪装成 MySQL 从库，通过复制协议拉取 binlog，把数据库变更实时分发到下游（搜索索引、缓存、数仓）。11111 承载它与客户端之间的订阅协议，下游程序连接的就是这个端口。
基本信息
| 服务 | Canal server |
|---|---|
| 协议 | TCP（Canal 订阅协议） |
| 默认端口 | 11111 |
| 上游依赖 | MySQL 复制权限账号与 binlog |
| 暴露面 | 仅数据链路网段 |
典型使用场景
- 数据库变更同步到 Elasticsearch 支撑搜索
- 同步到 Redis 做缓存失效
- 准实时同步进数仓或数据湖
- 异构系统之间的数据搬运
- 对账排查：把下游数据与 binlog 位点做比对
服务与位点核对
服务与位点核对
ss -lntp | grep 11111
grep -E 'canal.port|canal.instance.master' conf/example/instance.properties
tail -f logs/example/example.log # 位点与同步状态
tail -f logs/canal/canal.log # 服务端连接与错误排障与核对
| 检查项 | 做法 | 异常表现 |
|---|---|---|
| 服务监听 | ss -lntp | grep 11111 | 端口不在：Canal 未启动或端口被改 |
| 位点 | instance 日志中的 binlog 位点 | 位点不推进：上游无写入或复制中断 |
| 上游连接 | MySQL 上的复制连接状态 | 账号失效：日志报鉴权或权限错误 |
| 下游消费 | 下游应用的消费延迟 | 位点推进正常但下游积压：消费侧慢 |
同步「断了」时先分清是 Canal 没接到 binlog，还是下游消费不过来：前者看 instance 日志的位点与上游复制状态，后者看下游的消费延迟，两者的处置方式完全不同。
复制账号的权限边界
Canal 需要一个具备复制权限的 MySQL 账号来读取 binlog，权限范围只应覆盖需要的库表。为省事赋 ALL 时，一旦 Canal 主机被入侵，攻击者可以用这个账号长期读取甚至改写数据，而普通审计很难发现这条链路。
实例配置文件里保存着上游数据库地址与账号，文件权限要收紧；建议按业务分实例而不是所有同步共用一个实例，出问题时影响面更小，位点也更容易定位。
复制账号权限过大：Canal 主机被攻破等于数据库长期被潜伏在复制链路里，权限回收也会打断同步。