Canal 集群部署遇到的一些问题

canal 从应用上主要包含三个概念, canal-service(canal.properties),canal-instance(canal.properties),canal-admin, 前两者是一对多的概念, 且是一个整体, 比如一个 service 上可以部署多个 instance; 而 canal-admin 用于管理 canal-service.

最近一周在部署 canal 的 HA 集群版(v1.1.5), 把遇到的问题和一些体会总结下, 这篇文章不会以宏观的概念去理解 canal 的原理和设计理念, 但通过实践, 确实对 canal 的运维和设计有了更深刻的印象, 而且如果你习惯于原来的单机部署模式, 那么在部署集群版的时候, 可能会觉得不适应.

那么部署 HA 集群版的原因是什么呢? 首先如果按照传统的模式, 增加一个 instance 需要手动拷贝一份配置, 修改配置, 然后重启服务, 可操作性和可理解性非常差, 而集群版有了 UI 控制台, 非常的简单; 其次 canal service 可以做到横向扩容, 可用性上好了很多, 当然 canal admin 本身还是一个单点.

理解了这三者概念, 那么首先配置的就是 canal-admin, 当然我不会贴一张图, 官网上都有.

初始化数据库, 为了管理 service 和 instance, 需要一个 MySQL 数据库.

conf/application.YAML 中配置的 adminUser 和 adminPasswd 非常重要, 首先它用于登录 admin 后台, 但一旦修改后, 这个配置对于 admin 后台登录就没有用了.

它重要的原因在于 canal admin 和 canal service 通信校验会用到, 这后面会说.

接下去就是启动 canal-admin, 如果成功就在 8089 端口启动 UI 服务, 强烈建议查看 logs/admin.log 日志, 以便用于排查问题.

对于 admin 来说, 有两个配置非常重要, 就是 config 目录下的 canal-template.properties,instance-template.properties, 它们称为模板, 也就是说 service 和 instance 服务本地配置文件都没有用了, 它们都会读取 admin 的配置, 这样说明 service 服务会非常的轻量.

其次我们启动 canal-server 服务. 在运行的时候, 首先要有一个基本配置文件.

官方让 canal_local.properties 覆盖 canal.properties, 进一步说明 canal.properties 的配置在集群版完全无用, 这个 local 表明这是为了运行本地基础服务, 建立和 admin 的通讯.

sh bin/startup.sh local 或 sh bin/startup.sh 都可以启动. 也强烈建议查看 logs/canal/canal.log 文件用于排查问题.

然后看看基础配置包含什么:

# register ip
canal.register.ip =
# canal admin config
canal.admin.manager = 127.0.0.1:8089
canal.admin.port = 11110
canal.admin.user = admin
canal.admin.passwd = 4ACFE3202A5FF5CF467898FC58AAB1D615029441
# admin auto register
canal.admin.register.auto = true
canal.admin.register.cluster =

canal.register.ip 就是 service 的本地 IP,canal.admin.manager 是 admin 的远端地址, 在启动的时候用于连接 admin.

canal.admin.passwd 密码非常重要, 它会和 admin 做双向认证, canal-server 会以这个密文和 canal-admin 做请求, 同时 canal-admin 也会以密码原文生成加密串后和 canal-server 进行 admin 端口链接, 所以这里一定要确保这两个密码内容的一致性.

canal.admin.port 是 service 用于和 admin 建立通讯的端口.

canal.admin.register.cluster 我没去试验, 就是 service 启动的时候会自动加入 admin 配置的集群中(可以多个集群).

启动的时候我遇到一个问题, 提示 Caused by: com.alibaba.otter.canal.common.CanalException: requestGet for canal config error: canal.properties config is empty 错误. 原因就在于 service 启动的时候会先 admin 拉取 canal-template.properties 配置. 而我在 admin 启动后并没有立刻配置 canal-template.properties(困惑的是 canal-template.properties 这个配置动作属主是配置集群, 所以比较有疑惑性, 但看到 canal.admin.register.cluster, 我觉得对于每一台 service 来说, 它在设计中默认是只能配置为一个集群, 从这个集群配置中拉取 canal-template.properties, 这样理解就比较合理了)

接下去说说如何在 admin 上管理集群, service,instance.

首先要建立集群, 集群是通过 zookeeper 维护状态的, 那存储什么了呢? 个人觉得 service 连接 admin 的时候, 会把存储状态放到 zookeeper,admin 通过 zookeeper 获取 sercie 的节点信息, 当然可能还会存储其他的.

接下去配置 service 和 instance, 都是隶属关系. 这里面重点说下自己的理解.

设想是建立二个集群, 一个是 qa 集群, 一个是 online 集群, 但它们共用一群 service, 实际上在建立 service 的时候, 如果发现节点 (ip 和 port) 已经使用过, 就不允许建立了, 联想下上面提到的 canal.admin.register.cluster, 进一步释然了.

这说明对于一个 service 节点来说, 它只能连接一个集群, 在这种情况下, 如果为了区分 qa 集群和 online 集群, 那么就要配置不同的 service 节点(ip 和 port 不同就可以).

也做了一些测试验证漂移, 比如把某个 service 关闭, 那么 instance 上的所属主机就会漂移.

最后说说 service 和 instance 配置, 这里主要说基本的信息.

# tcp bind ip
canal.ip =
# register ip to zookeeper
canal.register.ip =
canal.port = 11111
canal.metrics.pull.port = 11112
canal.zkServers = xwj-zookeeper-1.com:2181,xwj-zookeeper-2.com:2181,xwj-zookeeper-3.com:2181
canal.serverMode = kafka
canal.instance.global.spring.xml = classpath:spring/default-instance.xml
kafka.Bootstrap.servers = xwj-kafka-1.com:9092,xwj-kafka-2.com:9092,xwj-kafka-3.com:9092
kafka.acks = all

现在看上去非常清晰, canal.port 是本地服务的端口, canal.metrics.pull.port 可以接入监控系统, 使用 kafka 作为队列, default-instance.xml 可以将 pos 信息同步到 zookeeper, 对于集群版我觉得只能配置它(没有测试), 原因一台 service 挂了, 接管的 service 必须知道消费到哪儿了.

canal.instance.master.address=
canal.instance.dbUsername=dts
canal.instance.dbPassword=!xi5jie@com#
canal.instance.connectionCharset = UTF-8
canal.instance.filter.regex=.*\\..*
canal.mq.partitionsNum=3
canal.mq.partitionHash=test.table:id^name,.*\\..*

这个就更简单了, 配置从那个数据库那个表监测 binlog, 然后同步到那个 kafka topic 中.

来源: http://database.51cto.com/art/202201/699272.htm

与本文相关文章

暂无,快来抢沙发吧！