阿里巴巴CanalAdmin部署以及Canal集群HA搭建

背景

canal-admin设计上是为canal提供整体配置管理、节点运维等面向运维的功能，提供相对友好的WebUI操作界面，方便更多用户快速和安全的操作

安装部署

1、下载地址：https://github.com/alibaba/canal/releases

2、解压后得到如下文件

3、配置修改如下图

4、初始化元数据库

初始化脚本在conf目录下

5、启动

sh bin/startup.sh

    

 

设计理念

canal-admin的核心模型主要有：

1. instance，对应canal-server里的instance，一个最小的订阅mysql的队列
2. server，对应canal-server，一个server里可以包含多个instance
3. 集群，对应一组canal-server，组合在一起面向高可用HA的运维

简单解释：

1. instance因为是最原始的业务订阅诉求，它会和 server/集群 这两个面向资源服务属性的进行关联，比如instance A绑定到server A上或者集群 A上，
2. 有了任务和资源的绑定关系后，对应的资源服务就会接收到这个任务配置，在对应的资源上动态加载instance，并提供服务
   • 动态加载的过程，有点类似于之前的autoScan机制，只不过基于canal-admin之后可就以变为远程的web操作，而不需要在机器上运维配置文件
3. 将server抽象成资源之后，原本canal-server运行所需要的canal.properties/instance.properties配置文件就需要在web ui上进行统一运维，每个server只需要以最基本的启动配置 (比如知道一下canal-admin的manager地址，以及访问配置的账号、密码即可)

 

配置项：

• 修改集群/删除集群，属于基本的集群信息维护和删除
• 主配置，主要是指集群对应的canal.properties配置，设计上一个集群的所有server会共享一份全局canal.properties配置 (如果有个性化的配置需求，可以创建多个集群)
• 查看server，主要是指查看挂载在这个集群下的所有server列表

Server运维

配置项：

• 所属集群，可以选择为单机 或者 集群。一般单机Server的模式主要用于一次性的任务或者测试任务
• Server名称，唯一即可，方便自己记忆
• Server Ip，机器ip
• admin端口，canal 1.1.4版本新增的能力，会在canal-server上提供远程管理操作，默认值11110
• tcp端口，canal提供netty数据订阅服务的端口
• metric端口， promethues的exporter监控数据端口 (未来会对接监控)

1. Server变更

配置项:

• 配置，主要是维护单机模式的canal.properties配置，注意：挂载到集群模式的server，不允许单独编辑server的canal.properties配置，需要保持集群配置统一
• 修改/删除，主要是维护server的基本属性，比如名字和ip、port
• 启动/停止，主要是提供动态启停server的能力，比如集群内这个机器打算下线了，可以先通过停止释放instance的运行，集群中的其他机器通过HA就会开始接管任务
• 日志，查看server的根日志，主要是canal/canal.log的最后100行日志
• 详情，主要提供查询在当前这个server上运行的instance列表，以server维度方便快速做instance的启动、停止操作. 比如针对集群模式，如果server之间任务运行负载不均衡，可以通过对高负载Server执行部分Instance的停止操作来达到均衡的目的

Instance运维

instance配置比较简单，主要关注：

• 资源关联，比如挂载到具体的单机 或 集群
• instance.properties配置维护，可以载入默认模板进行修改
• 

配置项:

• 修改，主要就是维护instance.properties配置，做了修改之后会触发对应单机或集群server上的instance做动态reload
• 删除，相当于直接执行instance stop，并执行配置删除
• 启动/停止，对instance进行状态变更，做了修改会触发对应单机或集群server上的instance做启动/停止操作
• 日志，主要针对instance运行状态时，获取对应instance的最后100行日志，比如example/example.log

CanalAdmin创建CanalHA

1、创建一个集群 

   填对应的集群名字和zookeeper地址 多个用逗号分隔

因为一个集群共享一份canal.properties,canalAdmin会提供一份标准的配置文件，直接载入模板即可

载入模板配置后，需要修改部分配置，如下

#canalserver的用户名和密码，密码需要用密文，客户端连接时需要（本文使用Kafka）
canal.user = canal
canal.passwd = 518BF4518E6412D1D0D06D38677D861B29F562CF
#canalAdmin的用户名和密码，密码用密文，用于canalServer连接admin使用
canal.admin.user = admin
canal.admin.passwd = 4ACFE3202A5FF5CF467898FC58AAB1D615029441
#zookee地址
canal.zkServers =192.168.111.131:2181,192.168.111.130:2181,192.168.111.128:2181

# tcp, kafka, rocketMQ, rabbitMQ  本文使用kafka
canal.serverMode = kafka
#全局的spring配置方式的组件文件 HA模式需要default-instance.xml
canal.instance.global.spring.xml = classpath:spring/default-instance.xml
#kafka集群地址
kafka.bootstrap.servers = 192.168.111.128:9092,192.168.111.130:9092,192.168.111.131:9092

 

2、新建CanalServer

此时创建了一个canalServer，但是它的状态是断开的，因为我们还没有启动canalServer，我们需要在对应的机器上上传好canalServer安装包（分别上传到192.168.111.128，192.168.111.131这两台机器上）。引入了canal-admin之后，canal-server之前面向命令行的运维方式需要有一些变化，主要的变化在于配置体系上，每个server节点上不应该再去维护复杂而且冗长的canal.properties/instance.properties，应该选择以最小化、无状态的方式去启动，因此在canal 1.1.4上，对于配置做了一些重构来支持canal-admin，同时也兼容了原先的命令行运维模式.

1. 引入canal_local.properties，针对canal-server启动所需要的配置，做了最小化配置，只需要关注和admin请求的必要参数即可

# register ip
canal.register.ip =

# canal admin config
canal.admin.manager = 192.168.111.131:8089
canal.admin.port = 11110
canal.admin.user = admin
canal.admin.passwd = 4ACFE3202A5FF5CF467898FC58AAB1D615029441 
# 是否开启自动注册模式
canal.admin.register.auto = true
# 可以指定默认注册的集群名，如果不指定，默认注册为单机模式
canal.admin.register.cluster =  canaltest
canal.admin.register.name =testserver01

针对canal.admin.passwd，这里默认做了密码加密处理，这里的passwd是一个密文，和canal-admin里application.yml里的密码原文做对应.

密文的生成方式，请登录mysql，执行如下密文生成sql即可(记得去掉第一个首字母的星号)

select password('admin')

+-------------------------------------------+
| password('admin')                         |
+-------------------------------------------+
| *4ACFE3202A5FF5CF467898FC58AAB1D615029441 |
+-------------------------------------------+

请注意几点：

1. 这个密码方式，同样对于canal.user.passwd有效 (1.1.4新增的，用于控制用户访问canal-server的订阅binlog的ACL机制)
2. canal.admin.user/canal.admin.passwd，这是一个双向认证，canal-server会以这个密文和canal-admin做请求，同时canal-admin也会以密码原文生成加密串后和canal-server进行admin端口链接，所以这里一定要确保这两个密码内容的一致性
3. canal.properties里的canal.id，目前已经废弃为基于canal.registerIp + canal.adminPort作为唯一标识，请求canal-admin来获取配置
4. instance.properties里的canal.instance.mysql.slaveId，这个在canal 1.0.26版本之后就已变更为随机生成，确保HA模式下slaveId的唯一性

3、启动

 ./startup.sh local

问题：如果启动不了（看下bin目录下出现此文件），可能是因为内存不足，canal启动内存设置的是3G,所有我们修改启动脚本startup.sh,修改好后启动

查看如下日志说明启动成功

刷新页面，说明canalAdmin已经连接到此server

4、新建instance

新建一个instance后，输入instance名称和挂在所有的集群，然后载入模板，修改好对应的master主库信息即可,然后启动instance,在对应的canalserver的conf下会创建一个instance文件夹

 

 

5、canal集群HA配置

Canal可以多个节点结合zookeeper组成高可用集群（主要是对每个instance做高可用），Canal集群中同时只有一个active状态的节点用来解析（多线程）bin log，如果有节点退出，之前节点已经解析完成的解析位点和消费位点会同步到zookeeper，另外的节点就会顶上去继续解析bin log（从zookeeper读取解析位点和消费位点），为下游客户端提供服务。Canal高可用集群依赖于zookeeper作为统一协调者，各个Canal server信息、Canal client信息、解析位点、消费位点会写入zookeeper；Canal客户端直接从zookeeper获取Canal服务端信息来消费，zk统一协调，保证只有一个Canal server处于激活状态。

我们将canalServer部署文件上传到另一台机器上，解压后配置如第一台机器,如下，然后启动

canal.register.ip =

# canal admin config
canal.admin.manager = 192.168.111.131: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 = canaltest
canal.admin.register.name = testserver02

此时在admin管理上可以看到一个集群下有两个server服务

6、查看zookeeper节点

  查看instance,目前所属的主机是testserver01,zookeeper节点128这台机器，

停止128这台机器上的canalServer

此时查看instance所属主机是testserver02以及对于的zookeeper节点已经切换

 

触发HA自动切换场景 (server/client HA模式都有效)

1. 正常场景

    a.  正常关闭canal server(会释放instance的所有资源，包括删除running节点)

    b.  平滑切换(gracefully)

         操作：更新对应instance的running节点内容，将"active"设置为false，对应的running节点收到消息后，会主动释放running节点，让出控制权但自己jvm不退出，gracefully. 

{"active":false,"address":"10.20.144.22:11111","cid":1}

2.  异常场景

   a.  canal server对应的jvm异常crash，running节点的释放会在对应的zookeeper session失效后，释放running节点(EPHEMERAL节点)

       ps. session过期时间默认为zookeeper配置文件中定义的tickTime的20倍，如果不改动zookeeper配置，那默认就是40秒

   b.  canal server所在的网络出现闪断，导致zookeeper认为session失效，释放了running节点，此时canal server对应的jvm并未退出，(一种假死状态，非常特殊的情况)      ps. 为了保护假死状态的canal server，避免因瞬间runing失效导致instance重新分布，所以做了一个策略：canal server在收到running节点释放后，延迟一段时间抢占running，原本running节点的拥有者可以不需要等待延迟，优先取得running节点，可以保证假死状态下尽可能不无谓的释放资源。 目前延迟时间的默认值为5秒，即running节点针对假死状态的保护期为5秒. 

 

与其浪费时间，在不属于你的世界里硬挤，不如学会得体地退出