写在前面

MySQL是互联网行业使用的最多的关系型数据库之一,而且MySQL又是开源的,对于MySQL的深入研究,能够加深我们对于数据库原理的理解。自从开源了mykit-data之后,不少小伙伴试用后,反馈mykit-data无法正确的解析MySQL8的binlog。于是我测试了下,mykit-data在解析MySQL5.x的binlog时,没有啥问题,能够正确的解析出结果数据。然而,在解析MySQL8.x的binlog时,总是与binlog日志位数相差12位而导致解析失败。

文章已收录到:

https://github.com/sunshinelyz/technology-binghe

https://gitee.com/binghe001/technology-binghe

问题修复

今天太晚了,我还在研究MySQL 8.0.20的源码,问题的修复过程后续再写一篇详细的文章来与小伙伴们分享下。这里,我就直接说我是如何解决这个问题的。

MySQL5.x binlog的解析结果与MySQL8.x binlog的解析结果总是存在位数偏差,框架原本的代码直接解析MySQL 5.x是没啥问题的,在解析MySQL 8.x的时候出现位数错误。

期间,我几乎翻阅了MySQL的所有官方文档,把mykit-data中关于解析binlog日志的功能重新写了一遍,解析MySQL5.x没问题,解析MySQL8.x还是错位。

到底哪里出了问题呢?就在对于问题的解决一筹莫展的时候,突然,想到一个思路:解决MySQL8.x binlog的时候不是总错位吗?那我就把多余位数的binlog数据读取出来,直接忽略掉,使后续binlog的解析操作对齐不就行了吗?

赶紧尝试一下,于是我在mykit-data框架的源码中,添加了如下代码。

在这里插入图片描述

上面代码是对解析MySQL binlog位数的校验和读取的封装,当读取的binlog位数未达到读取的限制位数时,一直读取binlog的数据,直到读取的binlog位数达到读取的限制位数位置。具体内部的逻辑,小伙伴们可以阅读mykit-data的源码。

加上这个逻辑后,进行测试验证,解析MySQL 8.x数据库的binlog竟然成功了!!困扰我几天的问题就这么在不经意间解决了!!

从解决这个问题的结果来看,MySQL8.x的binlog在本质上比MySQL5.x的binlog位数要长,中间会拼接用来分隔不同事件位的标识,我们在解析MySQL8.x的binlog日志时,可直接忽略掉这些分隔不同事件位的标识,目的就是让binlog的解析位对齐,从而能够正确的解析出下一个事件。而这样处理,也不会影响解析结果。

很多时候就是这样,当你苦于解决某个问题,迟迟找不到解决方案而一筹莫展时,在某个不经意的瞬间,就会无意中解决这个棘手的问题,但前提是你需要深刻理解它的原理并尝试各种方式和方法来解决它!

关于mykit-data

mykit-data是一款完全开源的数据异构中间件,支持插件化、可视化的数据异构框架,支持MySQL到MySQL、MySQL到Oracle、Oracle到MySQL、Oracle到Oracle的全量、实时/定时增量数据同步。完全的插件化、可视化操作。通过日志最大限度的避免同步过程中的数据丢失。支持失败重试,人工干预,支持查看同步的数据和详细的日志信息。

目前支持MySQL5.x、MySQL8.x,Oracle 11g及以上版本。后续会以插件的形式支持更多的异构数据源。

mykit-data的开源地址如下:

GitHub:https://github.com/sunshinelyz/mykit-data

Gitee:https://gitee.com/binghe001/mykit-data

最后,小伙伴们为这款开源项目点个Star呀!!

好了,今天就到这儿吧,我是冰河,大家有啥问题可以在下方留言,也可以加我微信:sun_shine_lyz,一起交流技术,一起进阶,一起牛逼~~

版权声明:本文为binghe001原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/binghe001/p/14299876.html