debezium 2.4 简介

Debezium connector for MySQL

MySQL存在一个二进制日志（binlog），按提交到数据库的顺序记录所有操作。这包括对表模式的更改以及对表中数据的更改。MySQL 使用 binlog 进行复制和恢复。 Debezium MySQL 连接器读取 binlog，为行级 INSERT、UPDATE 和 DELETE 操作生成更改事件，并将更改事件发送到 Kafka 主题。客户端应用程序读取这些 Kafka 主题。 由于 MySQL 通常设置为在指定时间后清除 binlog，因此 MySQL 连接器会对每个数据库执行初始一致快照。MySQL 连接器从制作快照时开始读取 binlog。

连接器是如何工作的

对连接器支持的 MySQL 拓扑进行概述有助于规划您的应用程序。要以最佳方式配置和运行 Debezium MySQL 连接器，了解连接器如何跟踪表的结构、显示模式更改、执行快照和确定 Kafka 主题名是很有帮助的。

支持的mysql 运行模式

单机版

使用单一 MySQL 服务器时，服务器必须启用 binlog（可选启用 GTID），以便 Debezium MySQL 连接器可监控服务器。这通常是可以接受的，因为二进制日志也可用作增量备份。在这种情况下，MySQL 连接器始终连接并跟踪此独立 MySQL 服务器实例。

mysql服务备份模式

Debezium MySQL 连接器可跟踪一个主服务器或一个副本（如果该副本启用了 binlog），但连接器只能看到该服务器可见的群集中的变化。一般来说，除了多主拓扑结构外，这不是问题。

连接器会在服务器的 binlog 中记录其位置，而群集中的每台服务器的 binlog 都不同。因此，连接器必须只跟随一个 MySQL 服务器实例。如果该服务器出现故障，必须先重启或恢复该服务器，然后才能继续使用连接器。

高可用集群

MySQL 有多种高可用性解决方案，它们大大简化了问题和故障的容忍度，几乎可以立即从问题和故障中恢复。大多数 HA MySQL 集群都使用 GTID，这样副本就能跟踪主服务器上的所有更改。

多主机模式

网络数据库（NDB）群集复制使用一个或多个 MySQL 复制节点，每个节点从多个主服务器进行复制。这是聚合多个 MySQL 集群复制的强大方法。这种拓扑结构需要使用 GTID。 Debezium MySQL 连接器可使用这些多主 MySQL 副本作为源，并可故障切换到不同的多主 MySQL 副本，只要新副本赶上旧副本即可。也就是说，新副本拥有第一个副本上的所有事务。即使连接器只使用数据库和/或表的子集，这也能起作用，因为在尝试重新连接到新的多主 MySQL 副本并在 binlog 中找到正确位置时，可以对连接器进行配置，以包括或排除特定 GTID 源。

托管模式

Debezium MySQL 连接器支持使用 Amazon RDS 和 Amazon Aurora 等托管选项。 由于这些托管选项不允许全局读锁，因此使用表级锁来创建一致快照。

历史结构主题

当数据库客户端查询数据库时，客户端使用数据库的当前结构。然而，数据库结构可以随时更改，这意味着连接器必须能够识别每次插入、更新或删除操作记录时的结构。此外，连接器不能只使用当前结构，因为连接器可能会处理表结构更改前记录的相对较旧的事件。

为确保正确处理结构更改后发生的更改，MySQL 在 binlog 中不仅包括对数据的行级更改，还包括应用到数据库的 DDL 语句。当连接器读取 binlog 并遇到这些 DDL 语句时，它会对其进行解析，并更新每个表的结构的内存表示。连接器使用该结构表示法来识别每次插入、更新或删除操作时的表结构，并生成相应的变更事件。在单独的数据库结构历史 Kafka 主题中，连接器会记录所有DDL语句以及每条DDL语句在binlog中出现的位置。

当连接器在崩溃或强制停止后重新启动时，连接器会从一个特定的位置，也就是从一个特定的时间点开始读取 binlog。连接器通过读取数据库结构历史 Kafka 主题，并解析 binlog 中连接器启动位置之前的所有 DDL 语句，重建此时存在的表结构。

该数据库结构历史主题仅供连接器使用。连接器可以选择将模式变更事件发送到另一个面向消费者应用的主题。

当 MySQL 连接器捕获应用了模式变更工具（如 gh-ost 或 pt-online-schema-change）的表中的变更时，会在迁移过程中创建辅助表。需要对连接器进行配置，以捕获这些辅助表的变化。如果消费者不需要为辅助表生成的记录，那么可以应用单一消息转换来过滤掉这些记录。

更多信息，请参阅接收 Debezium 事件记录的主题默认名称。