中间件兴趣圈

Canal 的 dump 支持串行和并行模式两种模式，本篇重点梳理 dump 的核心流程，以便对 dump 过程有一个充分的了解，更好的理解 Canal 的实现原理与细节，下一篇中将重点关注Canal是如何引入并行模式来提高dump的性能，即并行编程相关的技巧。从前面的文章我们得知 Canal binlog 日志解析的基本流程如下图所示：解析来重点梳理一下 dump 命令的发送逻辑，特别是日志的处理流程，一些基本的日志格式。1、 dump 流程分析在 Canal 中 dump 方法声明如下：带

本节目录1、Canal 位点管理（日志管理器）1.1 类图1.2 日志管理器使用方法2、MySQL GTID 扫盲正如上文提到的那样，在 Canal Instance 启动的时候，首先会查询日志管理器中查找上一次的同步位点，如果没有查询到，则默认会从最新的位点开始同步，但如果每一次启动Instance都从最后开始同步，其数据完整性无法保证，正确的做法是在数据同步的过程中应该记录位点并持久化，重新启动后按照继续从上一次的位置继续同步，实现真正的增量同步。本文就是来详细探讨 Canal的几个日志管理器，并来

本文将详细剖析Canal在初次启动时如何定位同步位点，行为思路先源码，再辅以流程图进行说明，并在总结部分使用思维导图进行总结，试图引发各位的讨论。本节目录1、Canal定位启动位点1.1 查找位点1.2 基于时间戳从查找 binlog 位点2、总结1、Canal定位启动位点在一个 Canal Instance 实例启动时，在向 MySQL 发送 dump 命令之前，首先先得计算该从 binlog 的什么位置开始同步，初次启动时如何寻找位点等。其代码如下图所示：从这里可以看成，将调用 findSta

本文将主要介绍在 EventParser binlog 日志同步流程中关于环形缓存区的使用技巧。1、环形缓存区关系型数据库讲究的是ACID 4个特性，故引入了数据库事务的概念，一个数据库事务中的多条SQL引发的多条数据变更要么全部成功，要么全部失败，即数据的一致性，那同样在数据同步的场景，在解析一个事务的 binlog 日志时，一次数据同步应该至少以事务为单位，一个事务内的所有 Event 应该作为一个批次提交到数据消费端，让消费端有能力一次同步一个事务中的数据，而不是一条一条变更日志的处理，这样容易造

本文将从三个方面深度剖析 EventParser 组件。从官方文档看 EventParser 的设计思想从 EventParser 初始化了解内部的是可配置项从 EventParser 的启动窥探其工作实现原理温馨提示：本篇篇幅较长，如果耐心阅读一定会有不错的收获，为了提高阅读体验，本文所有源码都是通过截图方式，大家可以重点阅读对应的文字说明，并在文末进行了总结。1、官方文档看 EventParser首先我们先从官方文档来看 EventParser 的整体设计，其架构设计图如下所示：

详细介绍了 Canal Instance 的设计理念，文末更是有彩蛋，抛出 canal 定制开发的思路与源码研究 Canal 的方法。

数据异构重磅武器 Canal 系列正式开始连载，本文是该系列的第一篇，从应用场景、架构设计理念 再到 在开发工具中跑通Demo，为后续带着自己的思考深入学习 canal打下坚实基础。如果本文对你有所帮助，麻烦点亮在看，能同时转发朋友圈更好