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

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

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

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

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

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

conf/application.yml中配置的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文件用于排查问题。

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

  1. # register ip 
  2. canal.register.ip = 
  3.  
  4. # canal admin config 
  5. canal.admin.manager = 127.0.0.1:8089 
  6. canal.admin.port = 11110 
  7. canal.admin.user = admin 
  8. canal.admin.passwd = 4ACFE3202A5FF5CF467898FC58AAB1D615029441 
  9. # admin auto register 
  10. canal.admin.register.auto = true 
  11. 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配置,这里主要说基本的信息。

  1. # tcp bind ip 
  2. canal.ip = 
  3. # register ip to zookeeper 
  4. canal.register.ip = 
  5. canal.port = 11111 
  6. canal.metrics.pull.port = 11112 
  7.  
  8. canal.zkServers = xwj-zookeeper-1.com:2181,xwj-zookeeper-2.com:2181,xwj-zookeeper-3.com:2181 
  9. canal.serverMode = kafka 
  10.  
  11. canal.instance.global.spring.xml = classpath:spring/default-instance.xml 
  12.  
  13. kafka.bootstrap.servers = xwj-kafka-1.com:9092,xwj-kafka-2.com:9092,xwj-kafka-3.com:9092 
  14. kafka.acks = all 

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

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

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

【编辑推荐】

【责任编辑:武晓燕 TEL:(010)68476606】

发表评论

邮箱地址不会被公开。 必填项已用*标注

  • 友情链接