Canal+Kafka实现Mysql数据同步

Canal介绍

canal [kə'næl]译意为水道/管道/沟渠主要用途是基于 MySQL 数据库增量日志解析提供增量数据订阅和消费

canal可以用来监控数据库数据的变化从而获得新增数据或者修改的数据。

canal是应阿里巴巴存在杭州和美国的双机房部署存在跨机房同步的业务需求而提出的。

阿里系公司开始逐步的尝试基于数据库的日志解析获取增量变更进行同步由此衍生出了增量订阅&消费的业务。

canal主要用途是基于 MySQL 数据库增量日志解析并能提供增量数据订阅和消费应用场景十分丰富。

目前canal主要支持mysql数据库。

github地址https://github.com/alibaba/canal

版本下载地址https://github.com/alibaba/canal/releases

文档地址https://github.com/alibaba/canal/wiki/Docker-QuickStart

Canal应用场景

1、电商场景下商品、用户实时更新同步到至Elasticsearch、solr等搜索引擎
2、价格、库存发生变更实时同步到redis
3、数据库异地备份、数据同步
4、代替使用轮询数据库方式来监控数据库变更有效改善轮询耗费数据库资源。

MySQL主从复制原理

1、MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events可以通过 show binlog events 进行查看)
2、MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
3、MySQL slave 重放 relay log 中事件将数据变更反映它自己的数据

Canal工作原理

• canal 模拟 MySQL slave 的交互协议伪装自己为 MySQL slave 向 MySQL master 发送 dump 协议
• MySQL master 收到 dump 请求开始推送 binary log 给 slave (即 canal )
• canal 解析 binary log 对象(原始为 byte 流)

  

Canal安装

参考文档https://github.com/alibaba/canal/wiki/QuickStart

Canal配置

mq相关参数说明 (>=1.1.5版本)

在1.1.5版本开始引入了MQ Connector设计参数配置做了部分调整

canal.mq.dynamicTopic 表达式说明

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

• 例子1test\\.test 指定匹配的单表发送到以test_test为名字的topic上
• 例子2.*\\..* 匹配所有表则每个表都会发送到各自表名的topic上
• 例子3test 指定匹配对应的库一个库的所有表都会发送到库名的topic上
• 例子4test\\..* 指定匹配的表达式针对匹配的表会发送到各自表名的topic上
• 例子5test,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下
• 例子4testA:test\\..* 指定匹配的表达式针对匹配的表会发送到testA的topic下
• 例子5test0: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多个配置之间使用逗号分隔

• 例子1test\\.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

mq顺序性问题

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

1. 1.

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

2. 2.

   canal支持MQ数据的几种路由方式单topic单分区单topic多分区、多topic单分区、多topic多分区

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

1. 1.

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

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

性能表现

Kafka + 混合DML场景测试

Kafka + 单表的batch insert场景测试

RocketMQ + 混合DML场景测试

RocketMQ + 单表的batch insert场景测试

附录

canal官方文档https://github.com/alibaba/canal/wiki/Canal-Kafka-RocketMQ-QuickStart

Canal+MQ性能表现https://github.com/alibaba/canal/wiki/Canal-MQ-Performance

参考文档https://www.cnblogs.com/zwh0910/p/17043265.html