Canal1.1.3安装文档

江畔独步

已于 2022-06-01 16:17:04 修改

阅读量1.2k

点赞数 1

分类专栏： Canal 文章标签： kafka 分布式 big data

于 2019-08-02 16:47:30 首次发布

本文链接：https://blog.csdn.net/liuwei0376/article/details/98211502

版权

Canal 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

基本说明

早期的canal版本（<1.1.1）,在部署完CanalSever后，仍需要开发数据消费代码，实现从canalserver拉取最新数据，根据指定JSON格式封装数据，最后发送到kafka这样的流程，整体架构如下图所示：

其中，canal client中需要编写大量复杂的逻辑校验代码，读取、解析binlog数据，实现数据同步至kafka等MQ中间件操作，具体交互处理流程如下图所示：

canal 1.1.1版本之后, 默认支持将canal server接收到的binlog数据直接投递到MQ, 目前默认支持的MQ系统有:

kafka: https://github.com/apache/kafka
RocketMQ : GitHub - apache/rocketmq: Mirror of Apache RocketMQ

环境版本

操作系统：CentOS release 6.6 (Final)
java版本: jdk1.8
canal 版本: 请下载最新的安装包，本文以当前v1.1.1 的canal.deployer-1.1.3.tar.gz为例
MySQL版本：5.7.18
注意：关闭所有机器的防火墙，同时注意启动可以相互telnet ip 端口

MySQL端准备工作

对于自建 MySQL , 需要先开启 Binlog 写入功能，配置 binlog-format 为 ROW 模式，my.cnf 中配置如下
```
[mysqld]
log-bin=mysql-bin # 开启 binlog
binlog-format=ROW # 选择 ROW 模式
server_id=1 # 配置 MySQL replaction 需要定义，不要和 canal 的 slaveId 重复
```
- 注意：针对阿里云 RDS for MySQL , 默认打开了 binlog , 并且账号默认具有 binlog dump 权限 , 不需要任何权限或者 binlog 设置,可以直接跳过这一步

授权 canal 链接 MySQL 账号具有作为 MySQL slave 的权限, 如果已有账户可直接 grant

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

一、安装zookeeper

参考：Zookeeper QuickStart

二、安装MQ

Kafka安装参考：Kafka QuickStart
RocketMQ安装参考：RocketMQ QuickStart

三、安装canal.server

3.1 下载压缩包

到官网地址(release)下载最新压缩包,请下载 canal.deployer-latest.tar.gz

3.2 将canal.deployer 复制到固定目录并解压

mkdir -p /usr/local/canal
cp   canal.deployer-1.1.1.tar.gz   /usr/local/canal
tar -zxvf canal.deployer-1.1.1.tar.gz

3.3 配置修改参数

a. 修改instance 配置文件 vi conf/example/instance.properties

#  按需修改成自己的数据库信息
#################################################
...
canal.instance.master.address=192.168.1.20:3306
# username/password,数据库的用户名和密码
...
canal.instance.dbUsername = canal
canal.instance.dbPassword = canal
...
# mq config
canal.mq.topic=example
# 针对库名或者表名发送动态topic
#canal.mq.dynamicTopic=mytest,.*,mytest.user,mytest\\..*,.*\\..*
canal.mq.partition=0
# hash partition config
#canal.mq.partitionsNum=3
#库名.表名: 唯一主键，多个表之间用逗号分隔
#canal.mq.partitionHash=mytest.person:id,mytest.role:id
#################################################

对应ip 地址的MySQL 数据库需进行相关初始化与设置, 可参考 Canal QuickStart

b. 修改canal 配置文件vi /usr/local/canal/conf/canal.properties

# ...
# 可选项: tcp(默认), kafka, RocketMQ
canal.serverMode = kafka
# ...
# kafka/rocketmq 集群配置: 192.168.1.117:9092,192.168.1.118:9092,192.168.1.119:9092 
canal.mq.servers = 127.0.0.1:6667
canal.mq.retries = 0
# flagMessage模式下可以调大该值, 但不要超过MQ消息体大小上限
canal.mq.batchSize = 16384
canal.mq.maxRequestSize = 1048576
# flatMessage模式下请将该值改大, 建议50-200
canal.mq.lingerMs = 1
canal.mq.bufferMemory = 33554432
# Canal的batch size, 默认50K, 由于kafka最大消息体限制请勿超过1M(900K以下)
canal.mq.canalBatchSize = 50
# Canal get数据的超时时间, 单位: 毫秒, 空为不限超时
canal.mq.canalGetTimeout = 100
# 是否为flat json格式对象
canal.mq.flatMessage = true
canal.mq.compressionType = none
canal.mq.acks = all
# kafka消息投递是否使用事务
canal.mq.transaction = false

mq相关参数说明

参数名	参数说明	默认值
canal.mq.servers	kafka为bootstrap.servers rocketMQ中为nameserver列表	127.0.0.1:6667
canal.mq.retries	发送失败重试次数	0
canal.mq.batchSize	kafka为`ProducerConfig.BATCH_SIZE_CONFIG` rocketMQ无意义	16384
canal.mq.maxRequestSize	kafka为`ProducerConfig.MAX_REQUEST_SIZE_CONFIG` rocketMQ无意义	1048576
canal.mq.lingerMs	kafka为`ProducerConfig.LINGER_MS_CONFIG` , 如果是flatMessage格式建议将该值调大, 如: 200 rocketMQ无意义	1
canal.mq.bufferMemory	kafka为`ProducerConfig.BUFFER_MEMORY_CONFIG` rocketMQ无意义	33554432
canal.mq.producerGroup	kafka无意义 rocketMQ为ProducerGroup名	Canal-Producer
canal.mq.canalBatchSize	获取canal数据的批次大小	50
canal.mq.canalGetTimeout	获取canal数据的超时时间	100
canal.mq.flatMessage	是否为json格式如果设置为false,对应MQ收到的消息为protobuf格式需要通过CanalMessageDeserializer进行解码	true
canal.mq.transaction	kafka消息投递是否使用事务, 主要针对flatMessage的异步发送和动态多topic消息投递进行事务控制来保持和canal binlog position的一致性, flatMessage模式下建议开启(需要kafka版本支持)。如果设置为false, flatMessage消息将会采用逐条同步的方式投递, 可能会产生消息丢失或者重复投递 rocketMQ无意义	false
---	---	---
canal.mq.topic	mq里的topic名	无
canal.mq.dynamicTopic	mq里的动态topic规则, 1.1.3版本支持	无
canal.mq.partition	单队列模式的分区下标，	1
canal.mq.partitionsNum	散列模式的分区数	无
canal.mq.partitionHash	散列规则定义库名.表名 : 唯一主键，比如mytest.person: id 1.1.3版本支持新语法，见下文	无

canal.mq.dynamicTopic 表达式说明

canal 1.1.3版本之后, 支持配置格式：schema 或 schema.table，多个配置之间使用逗号或分号分隔

例子1：test\\.test 指定匹配的单表，发送到以test_test为名字的topic上
例子2：.*\\..* 匹配所有表，则每个表都会发送到各自表名的topic上
例子3：test 指定匹配对应的库，一个库的所有表都会发送到库名的topic上
例子4：test\\.* 指定匹配的表达式，针对匹配的表会发送到各自表名的topic上
例子5：test,test1\\.test1，指定多个表达式，会将test库的表都发送到test的topic上，test1\\.test1的表发送到对应的test1_test1 topic上，其余的表发送到默认的canal.mq.topic值

为满足更大的灵活性，允许对匹配条件的规则指定发送的topic名字，配置格式：topicName:schema 或 topicName:schema.table

例子1: test:test\\.test 指定匹配的单表，发送到以test为名字的topic上
例子2: test:.*\\..* 匹配所有表，因为有指定topic，则每个表都会发送到test的topic下
例子3: test:test 指定匹配对应的库，一个库的所有表都会发送到test的topic下
例子4：testA:test\\.* 指定匹配的表达式，针对匹配的表会发送到testA的topic下
例子5：test0:test,test1:test1\\.test1，指定多个表达式，会将test库的表都发送到test0的topic下，test1\\.test1的表发送到对应的test1的topic下，其余的表发送到默认的canal.mq.topic值

大家可以结合自己的业务需求，设置匹配规则，建议MQ开启自动创建topic的能力

canal.mq.partitionHash 表达式说明

canal 1.1.3版本之后, 支持配置格式：schema.table:pk1^pk2，多个配置之间使用逗号分隔

例子1：test\\.test:pk1^pk2 指定匹配的单表，对应的hash字段为pk1 + pk2
例子2：.*\\..*:id 正则匹配，指定所有正则匹配的表对应的hash字段为id
例子3：.*\\..*:$pk$ 正则匹配，指定所有正则匹配的表对应的hash字段为表主键(自动查找)
例子4: 匹配规则啥都不写，则默认发到0这个partition上
例子5：.*\\..* ，不指定pk信息的正则匹配，将所有正则匹配的表,对应的hash字段为表名
- 按表hash: 一张表的所有数据可以发到同一个分区，不同表之间会做散列 (会有热点表分区过大问题)
例子6: test\\.test:id,.\\..* , 针对test的表按照id散列,其余的表按照table散列

注意：大家可以结合自己的业务需求，设置匹配规则，多条匹配规则之间是按照顺序进行匹配(命中一条规则就返回)

其他详细参数可参考Canal AdminGuide

canal.instance.filter.regex 表达式说明

通过正则表达式来筛选MySQL源库、源表：

语法： canal.instance.filter.regex=.*\\..*

mq顺序性问题

binlog本身是有序的，写入到mq之后如何保障顺序是很多人会比较关注，在issue里也有非常多人咨询了类似的问题，这里做一个统一的解答

canal目前选择支持的kafka/rocketmq，本质上都是基于本地文件的方式来支持了分区级的顺序消息的能力，也就是binlog写入mq是可以有一些顺序性保障，这个取决于用户的一些参数选择
canal支持MQ数据的几种路由方式：单topic单分区，单topic多分区、多topic单分区、多topic多分区

canal.mq.dynamicTopic，主要控制是否是单topic还是多topic，针对命中条件的表可以发到表名对应的topic、库名对应的topic、默认topic name
canal.mq.partitionsNum、canal.mq.partitionHash，主要控制是否多分区以及分区的partition的路由计算，针对命中条件的可以做到按表级做分区、pk级做分区等

canal的消费顺序性，主要取决于描述2中的路由选择，举例说明：

单topic单分区，可以严格保证和binlog一样的顺序性，缺点就是性能比较慢，单分区的性能写入大概在2~3k的TPS
多topic单分区，可以保证表级别的顺序性，一张表或者一个库的所有数据都写入到一个topic的单分区中，可以保证有序性，针对热点表也存在写入分区的性能问题
单topic、多topic的多分区，如果用户选择的是指定table的方式，那和第二部分一样，保障的是表级别的顺序性(存在热点表写入分区的性能问题)，如果用户选择的是指定pk hash的方式，那只能保障的是一个pk的多次binlog顺序性 ** pk hash的方式需要业务权衡，这里性能会最好，但如果业务上有pk变更或者对多pk数据有顺序性依赖，就会产生业务处理错乱的情况. 如果有pk变更，pk变更前和变更后的值会落在不同的分区里，业务消费就会有先后顺序的问题，需要注意