社区编辑申请
注册/登录
爷青回,Canal 1.1.6来了,几个重要特性和bug修复
数据库 MySQL
这里简单介绍了几个对我们生产中比较重要的优化和修复,具体更多内容大家可以直接去github上看release note。

刚刚在群里看到消息说,时隔一年,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修复和特性优化,还是非常值得升级的。

责任编辑:姜华 来源: 阿丸笔记
相关推荐

2022-06-20 22:37:25

Linux操作系统命令

2022-06-27 17:46:53

PythonFlask

2022-06-29 09:19:09

静态代码C语言c代码

2022-06-27 19:01:04

Python应用程序数据

2022-07-01 05:47:19

PyCharm插件开发

2022-06-23 11:42:22

MySQL数据库

2022-06-24 10:16:59

Python精选库

2022-06-23 12:43:36

区块链加密货币

2022-07-01 14:25:27

机器学习人工智能工业4.0

2022-06-24 10:52:47

人工智能作业帮T前线

2022-06-24 11:14:00

美团开源

2022-06-30 18:17:00

数据集云数据建模计数据仓库

2022-06-30 06:53:32

QQ泄露密码

2022-07-03 06:10:15

2022-06-23 09:22:57

Vue技巧前端

2022-06-23 12:03:00

网络安全网络安全事故

2022-06-28 10:58:35

勒索软件攻击事件

2022-06-20 13:34:46

漏洞网络攻击

2022-07-01 17:19:33

网络安全零信任

2022-06-27 08:07:13

Go语言互斥锁

同话题下的热门内容

一次非常有意思的 SQL 优化经历:从 30248.271s 到 0.001s为什么MySQL的count()方法这么慢?解决MySQL幻读的终极指南面试突击:说一下MySQL事务隔离级别?MySQL 死锁了,怎么办?分库分表实战:小试牛刀—千万级数据之SQL优化你知道MySQL中的游标吗?MySQL主键自增值为什么有“空洞”?

编辑推荐

MySQL集群搭建详解如果对MySQL还停留在这个印象,就out了防止服务器宕机时MySQL数据丢失的几种方案MySQL innodb引擎备份工具XtraBackup之二(数据库全备)MySQL优化: Slave延迟很大的优化方法总结
我收藏的内容
点赞
收藏

51CTO技术栈公众号