刚刚在群里看到消息说,时隔一年,canal 1.1.6正式release了,赶紧上去看看有什么新特性。
(居然才发布了6个小时,前排围观)
一、什么是canal
canal [kə'næl],译意为水道/管道/沟渠,主要用途是基于 MySQL 数据库增量日志解析,提供增量数据 订阅 和 消费。应该是阿里云DTS(Data Transfer Service)的开源版本。
如果想了解更多,可以上github上看官方文档,或者我之前写过的系列基于canal 1.1.4版本的入门文档。
二、重要新特性
我们现在生产用的还是1.1.4版本,用得还算稳定,没有什么特别大的bug。
这次,趁着升级了两个版本,看看1.1.5和1.1.6版本有什么新特性可以值得升级引入。
1、MQ发送优化
重点优化MQ发送的性能,单topic最高峰值可支持3~8万的rps,接近数量级上的性能提升
这是1.1.5中的重要特性优化。
为什么canal需要搭配MQ使用,甚至重点优化MQ的投递性能呢?
主要原因是 canal + MQ 可以打造强大的异构存储体系。
canal订阅binlog后有两种模式,一种是直接投递到一种介质,如mysql,一种是投递到MQ然后自定义消费。
如果采用投递到MQ的模式,那么我们就可以利用MQ进行一份消息多端消费(避免重复拉取binlog对MySQL造成影响),用于构建二级索引ES或者构建缓存Redis等等。
另一方面,投递mq以后,对于消息的回溯、监控都能提供更好的途径。
总的来说,canal这个特性优化给 canal + MQ 的模式带来了更加强大的支持。
2、MQ发送特性支持
新增rabbitmQ的MQ发送支持 #2156。
支持不同topic设置不同的分区数 #2173。
rocketMQ新增tag属性的定义 #3438。
参数配置支持env环境变量 #3450。
这是1.1.5中的一个小优化,但是我觉得非常重要。
比如rocketMQ新增tag属性的定义。实际上在我们的测试环境,就非常需要这个特性。
我们使用rocketMQ的tag做路由,如果业务方自行生产和消费,可以完全根据tag进行路由区分。而从canal订阅的数据库变更,1.1.4版本无法直接给消息打tag,业务消费就无法通过tag进行路由。
现在这个特性的优化,正好可以解决这个问题。
3、新增Puslar MQ支持
这是1.1.6中的一个小优化,还是非常与时俱进的。
目前的云原生消息队列Puslar MQ,凭借存储和计算分离的架构在云原生体系下如日中天,而canal就在最新版本支持了对Puslar MQ的投递,手动点赞。
三、重要bug修复
1、修复gtid模式下位点持久不更新的问题
这是1.1.5中修复的bug。
GTID又叫全局事务ID(Global Transaction ID),是一个已提交事务的编号,并且是一个全局唯一的编号。MySQL5.6版本之后在主从复制类型上新增了GTID复制。
为什么要引入这个东西呢?
- GTID使用master_auto_position=1代替了基于binlog和position号的主从复制搭建方式,更便于主从复制的搭建。
- GTID可以知道事务在最开始是在哪个实例上提交的。
- GTID方便实现主从之间的failover,再也不用不断地去找position和binlog 了。
为什么我特别关注到这个bug的修复呢?
因为我在2020年对canal 1.1.4进行poc的时候,就发现这个bug了,当时还吐槽了一波,233333。
一晃两年过去了,没想到在1.1.5中已经修复了,手动点赞。
2、修复RDB同步下的关键字引起的同步报错
这是1.1.6中修复的bug。
对于这个bug,也是有点记忆犹新。
当时在莫干山度假,突然早上八点收到线上警报,发现数据同步出现异常。
好在随身带了电脑(程序员出远门必备,sigh~),经过排查后发现,就是一个表结构变更引入的关键字导致了同步异常。
往事不堪回首。。。
四、总结
这里简单介绍了几个对我们生产中比较重要的优化和修复,具体更多内容大家可以直接去github上看release note。
总的来说,1.1.5和1.1.6都做了非常多的bug修复和特性优化,还是非常值得升级的。
免责声明:本平台仅供信息发布交流之途,请谨慎判断信息真伪。如遇虚假诈骗信息,请立即举报
举报