Canal binlog 日志管理器与GTID简介

正如上文提到的那样，在 Canal Instance 启动的时候，首先会查询日志管理器中查找上一次的同步位点，如果没有查询到，则默认会从最新的位点开始同步，但如果每一次启动 Instance 都从最后开始同步，其数据完整性无法保证，正确的做法是在数据同步的过程中应该记录位点并持久化，重新启动后按照继续从上一次的位置继续同步，实现真正的增量同步。

本文就是来详细探讨 Canal 的几个日志管理器，并来探究一下 MySQL 的 GTID 机制。

1、Canal 位点管理（日志管理器）

1.1 类图

整个日志管理器由接口 CanalLogPositionManager 定义，主要定义两个方法：

  • LogPosition getLatestIndexBy(String destination) 根据 destination 获取同步位点，即在 Canal Instance 中同步进度是以源实例为最小维度的。

  • void persistLogPosition(String destination, LogPosition logPosition) 持久化同步位点。

Canal 中提供了7种位点管理机制，分别如下：

  • MemoryLogPositionManager 同步位点存储在内存中，即存放在 Map 中，通常用于测试或结合其他位点管理，用来提高性能。

  • ZooKeeperLogPositionManager 同步位点存储在 zookeeper 中，是主流的分布式存储方案。

  • MetaLogPositionManager Canal 中的元数据存储方式，即位点信息与元数据存放在一起。

  • MixedLogPositionManager 混合日志位点管理器，主要是内存与 Zookeeper 的混合方式，在存储位点时先存入内存，然后用线程池异步存储到 zookeeper 中。

  • FileMixedLogPositionManager 基于内存与本地文件的混合日志管理器，存储位点时首先存入内存，然后定时同步到文件中。

  • PeriodMixedLogPositionManager 带定时功能的基于内存与 zookeeper 的混合日志管理器，存储位点时先写入内存，然后定时同步到 zookeeper。

  • FailbackLogPositionManager 带　failback　机制的日志位点管理器，即可以创建准备两种日志管理器，例如在构建时可以将 ZooKeeperLogPositionManager 当为主管理器，基于 FileMixedLogPositionManager 当备用日志位点管理器，在写入日志位点时，尝试写入主日志管理器，如果抛出异常，则使用备用日志管理器；查询位点时先查主日志管理器，如果未查到，则查备用日志管理器。

1.2 日志管理器使用方法

由于 Canal 日志管理器的实现比较简单，这里就不一一去看源码了，那这里就重点介绍一下其使用方法。

CanalInstanceWithManager#initLogPositionManager
从这里可以看到，Canal 提供了 indexMode 属性来指定使用哪种日志管理器，其可选项：

  • MEMORY 内存

  • ZOOKEEPER 基于zookeeper，使用该模式还需要通过 zkClusters 设置 zk 集群的地址。

  • MIXED 混合模式，基于内存+Zookeeper + Period，即定时存储到 zookeeper 中，使用的实现类为MixedLogPositionManager，默认为每隔1s持久化一次。

  • META 基于元数据的管理模式。

  • MEMORY_META_FAILBACK 基于内存与元数据的fallback，其中主日志管理器为 MEMORY。

在生产环境，通常建议使用 MIXED，基于内存与Zookeeper的混合模式。

2、MySQL GTID 扫盲

在 MySQL5.6.x 中引入了 GTID 机制，用于优化主从同步机制，本文不打算详细介绍 GTID 的方方面面，只是初步认识 GTID，方面在后续实现数据同步方面思考数据一致性如何保证等方案时具备必要的基础。

首先我们可以通过如下命令查看与gtid相关的属性。

在这里插入图片描述
主要的变量的含义如下：

  • gtid_executed 当前MySQL实现已经执行过的事务。在开启GTID模块时每执行一个事务会产生一个全局唯一的事务ID。在每一台MySQL实例上执行的事务何止上亿，这个字段要存储所有已执行的的事务ID，怎么存储能节省空间就是一个需要解决的问题，稍后再进行展开说明。

  • gtid_executed_compression_period 在MySQL5.7版本专门引入了一个系统表：mysql.gtid_executed，gtid_executed_compression_period 参数就是设置每执行多个事务，对这个表进行压缩，默认值为1000。

  • gtid_mode 是否开启gtid模式。

  • gtid_purged 已不在 binlog 日志中的事务ID，Mysql 并不会永久存储 binlog 日志，而是通过 expire_logs_days 设置过期时间，单位为天，默认为10天。

一个GTID由两部分组成：server id uuid 与递增序号，两者之间用英文冒号隔开，例如上图中的：1f0eee4c-a66e-11ea-8999-00dbdfe417b8:1。

再来回到 gtid_executed 的存储问题上，为了减少存储空间，连续的gtid可以用进行合并，例如 1f0eee4c-a66e-11ea-8999-00dbdfe417b8:1-10，表示连续代表1-10个事务。

GTID的生成有自动递增与手动执行模式，自动递增模式可以在单个Server集群中保证有序，即GTID值越大，说明事务越后执行，但如果进行了人工干预，GTID就不是越大越先执行了，举例如下：

通过如下命令手动指定gtid：
set gtid_next='1f0eee4c-a66e-11ea-8999-00dbdfe417b8:10';
begin;
commit;
set gtid_next='AUTOMATIC';
故这里产生了另外一个事件，其gtid 为 10,下一条语句产生的GTID会是 11 还是 4 呢？
从这里看成，会先使用空洞，其binlog记录如下。
从这里看出，在后续避免数据顺序性方面，使用GTID并不是一个十全的方法，基于binlog的写入时间更为靠谱。

欢迎加入我的知识星球，一起交流源码，探讨架构，揭秘亿级订单的架构设计与实践经验，打造高质量的技术交流圈，为广大星友提供高质量问答服务，长按如下二维码加入。