Debezium日常分享系列之：Debezium 2.4.0.Final发布

一、重大改变

虽然尽力避免次要版本之间发生任何潜在的重大更改，但此类更改有时是不可避免的。 Debezium 2.4 的升级总共包括 10 项独特的重大更改：

MySQL：

• 使用 bigint.unsigned.handling.mode 将连接器配置为精确时，未正确设置 BIGINT 数据类型的精度。如果使用具有上述配置设置的架构注册表，则此版本可能会导致架构不兼容，并且可能需要注册表调整。

MongoDB：

• 配置属性 mongodb.hosts 和 mongodb.members.autodiscover 已被删除。应使用连接字符串更新连接器配置。
• 建立连接时，优先选择辅助连接，这使得用户无法使用主连接。连接器现在将使用连接字符串来影响连接位置。

Oracle：

• snapshot.fetch.size 和 query.fetch.size 配置属性的默认值从 2000 更改为 10000，以提高连接器默认配置的性能。
• 系统更改号 (SCN) JMX 指标公开为基于字符串的数据类型，现在是 BigInteger 数据类型，从而可导出到可观察性堆栈。

Vitess：

• 更改事件结构已更改，源信息块现在包含一个新字段，用于标识事件源自的分片。
• 以 _bin 结尾的排序规则被推断为 VARBINARY 数据类型，将它们作为二进制数据发出；但是，对于基于字符的列，这是不正确的。如果您使用这些排序规则类型和架构注册表，这可能会导致架构不兼容，并且可能需要进行一些注册表调整。
• 架构更改之前应用于所有分片，而不是独立处理每个分片。如果您使用的是 DefaultTopicNamingStrategy 或其衍生策略，则应切换到 TableTopicNamingStrategy 以保留之前使用的相同主题命名。
• 默认情况下仅重试一部分错误。此行为已更改，现在默认情况下会重试所有错误，并且只有预定义错误条件的子集不会重试。

Debezium Server：

• Debezium Server 现在包含 Cassandra 连接器的所有变体，并添加了新的环境变量 EXTRA_CONNECTOR 来控制要使用的特定 Cassandra 连接器。该变量可以设置为 dse、cassandra-3 或 cassandra-4。

二、Debezium核心变化

1.Ad-hoc阻止快照

• 增量快照于大约两年前在 Debezium 1.6 中首次引入，并且在社区中仍然非常受欢迎，用于处理各种重新快照用例。然而，在某些用例中，读取事件与创建、更新和删除的交织性质可能不太理想，甚至某些消费者应用程序不支持。对于这些用例，Debezium 2.4 引入了临时阻塞快照。
• 临时阻塞快照的工作方式与临时增量快照的工作方式类似；然而，有一个主要区别。快照仍然是通过向 Debezium 发送信号来触发；然而，当连接器处理信号时，主要区别在于，在快照进程运行时，流传输被搁置。这意味着您不会收到一系列与创建、更新或删除事件交织在一起的读取事件。这也意味着我们将以与传统快照类似的方式处理快照，因此吞吐量通常应该高于增量快照。
• 请注意，临时阻塞快照会在执行快照时暂停事务日志的读取。这意味着在使用这种类型的临时快照模式时，传统快照对事务日志可用性的相同要求也适用。当流恢复时，如果所需的事务日志已被删除，连接器将引发错误并停止。

启动临时阻塞快照的信号与其对应的临时增量快照非常相似。下面的信号显示了对具有条件的特定表进行快照的有效负载，但这使用新的阻塞快照而不是增量快照：

{
  "type": "execute-snapshot",
  "data": {
    "data-collections": ["public.my_table"],
    "type": "BLOCKING", 
    "additional-condition": "last_update_date >= '2023-01-01'"
  }
}

使用 BLOCKING 而不是 INCRMENTAL 区分了两种临时快照模式。

2.错误处理

一些 Debezium 连接器以前使用连接器属性，errors.max.retries。此属性控制 Debezium 连接器失败异常显式包装在 RetriableException 中的频率，但连接器将原始异常抛出到运行时。虽然这听起来类似于 Kafka Connect 的 error.retry.timeout，但这实际上为用户提供了一种跨多个 Debezium 运行时（包括 Kafka Connect、Debezium Server 和 Debezium Embedded）处理重试的通用方法。

3.初始快照通知

Debezium 的新通知子系统提供了一种将第三方工具和应用程序与 Debezium 集成的简单方法，以深入了解持续的变更数据捕获过程，超越传统的 JMX 方法。在 2.4 中，通知子系统现在能够通知您正在进行的初始快照的状态。

初始快照通知以初始快照的聚合类型发出，并包含公开快照当前状态的类型字段。可能的值包括：STARTED、ABORTED、PAUSED、RESUMED、IN_PROGRESS、TABLE_SCAN_COMPLETED 和 COMPLETED。

4.带有 JSON 用户数据的 JMX 通知

Debezium 2.4 改变了 JMX 通知提供用户数据的方式。在以前的版本中，通知使用 toString() 样式实现，虽然它可以工作，但与其他更结构化的格式（例如 JSON）不同，它没有提供任何良好的向前或向后兼容性语义。

展望未来，JMX 通知的用户数据将以 JSON 形式提供，使其更容易、更可靠地解析并支持未来的可扩展性，同时减少对向后兼容性的担忧。希望这能让这个功能更容易使用，并欢迎任何额外的反馈。

5.通知

所有通知事件现在都将包含时间戳。

6.Source-to-sink的列名称传播

通常，当由接收器连接器（例如 JDBC 连接器）使用时，列名称直接映射到字段名称，反之亦然。然而，在某些情况下，序列化技术（例如 Avro）对于字段命名约定有非常具体的规则。当数据库表中的列名称与序列化规则的命名约定冲突时，Debezium 将重命名该事件中的字段，以使其遵守序列化规则。这通常意味着字段将在前面添加下划线或用下划线替换无效字符。

这可能会给某些类型的接收器（例如 JDBC 接收器连接器）带来问题，因为接收器无法轻松推断出目标表的原始列名称，也无法在事件的字段名称和列名称不同时充分映射它们。这通常意味着用户必须在接收器端使用转换链，以便使用代表源的命名来重建事件的字段。

Debezium 2.4 引入了一种方法，通过将原始列名作为字段模式参数传播来最小化并可能完全避免这种情况，这与我们对数据类型、精度、小数位数和长度的处理方式非常相似。当启用列或数据类型传播时，架构参数 __debezium.source.column.name 现在包含原始列名称。

Debezium JDBC 接收器连接器已经可以处理列和数据类型传播，允许接收器连接器更准确地推断列类型、长度、精度和小数位数。

有了这个新功能，当提供此参数时，JDBC 接收器连接器将自动使用该参数中的列名，以保证使用与源相同的列名创建目标表，即使使用 Avro 或类似的列名也是如此。这意味着使用 Debezium JDBC 接收器连接器时不需要进行任何转换。

7.时区转换

经常从社区听到的一个常见请求是使用 UTC 之外的其他时区来发出时间列。 Debezium 通过使用 CustomConverter 来更改默认发出时间列的方式来支持这一点，以编写您自己的单个消息转换；然而，这些方法可能并不适合所有人。

Debezium 2.4 现在附带了全新的时区转换，使您能够在粒度级别上控制发出的事件中的哪些时间列将从 UTC 转换为管道所需的任何所需时区。要开始进行此新转换，请将以下基本配置添加到您的连接器：

{
  "transforms": "tz",
  "transforms.tz.type": "io.debezium.transforms.TimezoneConverter",
  "transforms.tz.converted.timezone": "America/New_York"
}

通过指定上述配置，以 UTC 发出的所有时间列都将从 UTC 转换为 America/New_York 时区。但您不仅限于更改所有时间字段的时区，您还可以使用 include.fields 属性定位特定字段，如下所示：

{
  "transforms": "tz",
  "transforms.tz.type": "io.debezium.transforms.TimezoneConverter",
  "transforms.tz.converted.timezone": "America/New_York",
  "transforms.tz.include.fields": "source:customers:created_at,customers:updated_at"
}

在上面的示例中，第一个条目将转换源表名称为customers 的created_at 字段，而后者将转换主题名称为customers 的updated_at 字段。此外，您还可以使用 except.fields 从转换中排除字段，以将转换应用于除子集之外的所有字段：

{
  "transforms": "tz",
  "transforms.tz.type": "io.debezium.transforms.TimezoneConverter",
  "transforms.tz.converted.timezone": "America/New_York",
  "transforms.tz.exclude.fields": "source:customers:updated_at"
}

在上面的示例中，所有时态字段都将转换为 America/New_York 时区，除非源表名称为customers且字段为updated_at。

三、MongoDB

集群范围的权限

• 监视单个数据库或集合时不再需要集群范围的权限。

可配置的聚合管道顺序

• Debezium 2.4 现在提供了一种控制变更流管道聚合顺序的方法。当聚合特定文档时，这可能非常重要，这可能会导致管道问题（例如大文档）。
• 默认情况下，连接器应用 MongoDB 内部管道过滤器，然后应用任何用户构建的过滤器；然而，这可能会导致大型文档进入管道，并且如果文档超出内部 16Mb 限制，MongoDB 可能会抛出错误。在此类用例中，连接器现在可以配置为将用户阶段应用到首先由cursor.pipeline 定义的管道，以过滤掉此类用例，以避免管道由于16Mb 限制而失败。
• 要实现此目的，只需将以下配置应用于连接器：

{
  "cursor.pipeline.order": "user_first",
  "cursor.pipeline": "<custom-pipeline-filters>"
}

自定义认证

• 在AWS等特定环境中，需要使用AWS IAM基于角色的身份验证来连接MongoDB集群；但是，这需要使用 AWS_CREDENTIAL_PROVIDER 设置属性。该提供程序负责创建会话并提供凭据。
• 为了在此类环境中更无缝地集成，添加了一个新的配置属性 mongodb.authentication.class，它允许您直接在连接器配置中定义凭据提供程序类。如果您需要使用此类提供程序配置，您现在可以将以下内容添加到连接器配置中：

{
  "mongodb.authentication.class": "<fully-qualified-class-name-to-use>",
  "mongodb.user": "username",
  "mongodb.password": "password"
}

• 此外，如果身份验证需要使用除 admin 之外的其他数据库，连接器配置还可以包含 mongodb.authsource 属性来控制应使用哪个身份验证数据库。

过滤匹配模式

• 为 MongoDB 添加了一个新的配置属性，filtering.match.mode，以允许指定如何处理过滤。该属性可以用正则表达式或文字值指定。

MongoDB 7

• MongoDB 7.0 上个月刚刚发布，Debezium 2.4 附带了 MongoDB 7 支持。

并行增量快照

• 自从 Debezium 1.x 中引入增量快照以来，对现有数据进行增量快照并同时捕获数据库事务更改的过程一直是单线程活动。添加新功能以关注基础知识并在此基础上构建的情况并不罕见，这正是 MongoDB 所发生的情况。
• 在 Debezium 2.4 中，我们采取了第一步，通过并行读取多个块，使用 MongoDB 连接器为增量快照添加并行支持。在收集、排序块以及针对事务日志捕获数据集进行重复数据删除时，这应该允许以内存为代价实现更快的吞吐量。

读取优先：

• 读取从连接字符串获取的首选项。

身份验证变更：

• 支持 TC MongoDB 部署的身份验证。

四、MySQL

替代驱动程序支持

• 为了在 AWS 上使用 IAM 身份验证，需要特殊的 MySQL 驱动程序来提供此类功能。使用 Debezium 2.4，您现在可以提供对此特定驱动程序的引用，连接器将使用该驱动程序，而不是连接器附带的默认驱动程序。
• 例如，要在 AWS 上使用 IAM 身份验证进行连接，需要以下配置：

database.jdbc.driver=software.aws.rds.jdbc.mysql.Driver
database.jdbc.protocol=jdbc:mysql:aws

• database.jdbc.driver 指定应由连接器加载并用于与 MySQL 数据库通信的驱动程序。 database.jdbc.protocol 是补充配置属性，并非在所有上下文中都需要。它默认为 jdbc:mysql，但由于 AWS 需要 jdbc:mysql:aws，因此您可以在配置中指定此派生项。

并行快照架构事件

• MySQL 连接器将在快照阶段使用并行化生成架构事件。这应该可以提高捕获数据库中许多表的架构时的整体性能。我们计划研究如何将其扩展到其他关系连接器。

五、PostgreSQL

PostgreSQL 16

• 就在一周前，PostgreSQL 宣布立即发布 PostgreSQL 16，我们很高兴地宣布 Debezium 2.4 将支持该版本。
• PostgreSQL 16引入了备用服务器的逻辑复制；然而，该功能尚未经过 Debezium 测试，并将在 Debezium 的后续版本中引入。目前，逻辑复制仍然仅通过主服务器支持。

TimescaleDB支持：

• TimescaleDB 是一个基于 PostgreSQL 的开源时间序列数据库。这意味着支持 TimescaleDB 的大量功能直接来自现有的 PostgreSQL 连接器；然而，TimescaleDB 的某些方面（例如块、超表和聚合）并非如此。
• 因此，如果您想开始使用 Debezium 2.4 和 TimescaleDB，则集成需要将 PostgreSQL 连接器与新的 TimescaleDb 单消息转换 (SMT) 结合起来。这两者的组合提供了从 TimescaleDB 环境流式传输更改的能力，并具有基于块、超表和聚合的适当表名称。
• TimescaleDb 转换以 io.debezium.connector.postgresql.transforms.timescaledb 形式提供，负责在处理块、超表和聚合时调整最终主题名称。此外，此转换将元数据标头添加到更改事件中，以便您相应地了解原始块名称、块表、超表模式和表名称。

六、Oracle

嵌入式 Infinispan 全局配置支持

• Oracle 连接器支持三种不同的缓冲技术，一种基于 JVM 堆，另两种基于使用 Infinispan 的堆外存储。使用 Infinispan 时，您可以选择使用远程集群（其中通过远程连接存储和管理缓存）或使用嵌入式集群（其中集群由连接器本身在本地管理）。
• 使用远程 Infinispan 集群时，会有一些集群配置作为 Infinispan 安装本身的一部分进行，这通常称为全局或集群配置。然而，在使用嵌入式 Infinispan 集群时，Debezium 只是使用嵌入式集群的默认配置，这可能并不总是为每个环境提供所有必要的行为。
• Debezium 2.4 引入了一个新的配置属性 log.mining.buffer.infinispan.cache.global。此属性允许为 Infinispan"全局"或"集群"配置指定 XML 配置。

配置示例

<infinispan>
  <threads>
    <blocking-bounded-queue-thread-pool
        max-threads="10"
        name="myexec"
        keepalive-time="10000"
        queue-length="5000" />
  </threads>
</infinispan>

借助 Debezium 2.4，如果您使用 Infinispan 嵌入式缓冲区，您现在可以安全地配置 Infinispan 的整体嵌入式全局配置，这可以让您在使用嵌入式 Infinispan 引擎时调整和提高整体性能。

最大交易期限指标

• Oracle 连接器为 LogMiner 提供了大量指标，包括代表连接器事务缓冲区中最早的系统更改编号的 OldestScn 指标。此 SCN 可用于了解相对于当前系统更改编号 CurrentScn 仍可缓冲事务的时间。然而，系统更改编号只是需要使用数据库函数调用才能知道更改何时发生的数值。
• 从 Debezium 2.4 开始，连接器现在还将通过提供名为 OldestScnAgeInMilliseconds 的新指标来跟踪最旧的系统更改编号的年龄。该指标是通过获取 OffsetScn 的时间戳并计算该时间与该指标的查询时间之间的差值来计算的，从而给出缓冲区中尚未提交或回滚的最旧事务的粗略年龄（以毫秒为单位）。

OpenLogReplicator 摄取方法

• Debezium for Oracle 连接器传统上附带两个适配器，一个用于 Oracle XStream，另一个用于直接与 Oracle LogMiner 集成。虽然每个适配器都有自己的优点，并且在功能和对各种数据类型和用例的支持方面都相当成熟，但我们希望探索一种完全不同的捕获更改的方式。
• Debezium 2.4.0.Beta2 引入了一个基于 OpenLogReplicator 的新的实验性 Oracle 摄取适配器。该适配器直接与 OpenLogReplicator 进程集成，以便以类似于 XStream 实现充当 Oracle GoldenGate 客户端的方式创建更改事件。
• OpenLogReplicator 是一个独立进程，必须在 Oracle 数据库服务器上运行，或者可以独立于数据库服务器运行，但需要通过 TCP/IP 与数据库直接通信，并对 Oracle 重做和归档日志文件具有直接读取访问权限。 OpenLogReplicator 也不附带任何预构建的二进制文件，因此代码必须直接从源代码构建或部署在可以通过文件共享远程访问数据库及其文件的容器映像中。

安装 OpenLogReplicator 后，设置需要执行以下步骤：

• 配置 OpenLogReplicator 的配置 OpenLogReplicator.json。
• 配置 Oracle 连接器以使用 OpenLogReplicator 适配器。

此时，Debezium for Oracle 连接器期望 OpenLogReplicator 配置使用非常具体的设置，以便使用正确的序列化将数据传输到连接器。示例配置显示了 Debezium 必须设置的关键配置参数才能正确摄取数据。

配置 OpenLogReplicator 后，您应该看到 OpenLogReplicator 以以下内容启动：

OpenLogReplicator v1.2.1 (C) 2018-2023 by Adam Leszczynski (aleszczynski@bersler.com), see LICENSE file for licensing information, arch: x86_64, system: Linux, release: 6.4.11-200.fc38.x86_64, build: Debug, modules: OCI Probobuf
adding source: ORACLE 
adding target: DBZ-NETWORK 
writer is starting with Network:0.0.0.0:9000 

• OpenLogReplicator.json 中配置的源别名
• OpenLogReplicator.json 中配置的目标别名
• OpenLogReplicator 正在侦听的主机和端口。

最后要配置连接器，请设置以下连接器配置选项：

{
  "database.connection.adapter": "olr",
  "openlogreplicator.source": "<source-alias>", 
  "openlogreplicator.host": "<host>", 
  "openlogreplicator.port": "<port>" 
}  

• 要使用的 OpenLogReplicator.json 配置中定义的源别名。
• 运行 OpenLogReplicator 的主机。
• OpenLogReplicator 正在侦听的端口。

当连接器启动并开始流式传输时，它将连接到 OpenLogReplicator 进程的网络端点，与序列化进程协商连接，然后开始接收重做日志条目。

XML 和 RAW 数据类型

• Debezium 2.4 支持多种新的 Oracle 数据类型，其中包括 XML_TYPE 和 RAW (DBZ-3605)。支持 XML 需要两个新的 Oracle 依赖项：xdb 和 xmlparserv2。这些依赖项不可重新分发，因此默认情况下它们不包含在连接器插件存档中，就像连接器的驱动程序一样。您必须直接从 Maven Central 或 oracle 获取这些，就像驱动程序依赖项一样。
• 此外，XML 的工作方式与 CLOB 和 BLOB 数据类型类似；因此，必须将连接器配置为 lob.enabled 设置为 true 才能接收 XML 更改。

七、SQL Server

心跳改善

• 数据库在一段时间内没有任何相关更改的情况并不罕见，无论是由于不活动还是由于配置而发生的连接器不感兴趣的更改。在这些情况下，连接器管理的偏移元数据在这些时间段内保持与偏移后备存储同步至关重要，以便连接器的重新启动按预期工作。
• 在 Debezium 2.4 中，如果 SQL Server 更改捕获循环未发现任何更改，或者已发生的更改与连接器没有任何相关性，则连接器在启用时将继续发出心跳事件。这应该可以提高在各种用例中存储在偏移量后备存储中的偏移量的可靠性。

八、JDBC

改进的表命名策略

• 添加了从更改事件的源信息块引用值的功能，作为连接器配置属性 table.name.format 的一部分。如果要引用此类字段，只需在配置中使用 ${source.} 即可，并且将使用该字段的值。

基于标头的主键

• 从更改事件上定义的标头解析行主键的能力。要使用此新功能，请将连接器配置属性primary.key.mode指定为record_header。如果标头值是原始类型，您将需要定义一个 Primary.key.fields 配置，类似于事件的记录键是原始类型时的配置。如果标头值是结构类型，则默认情况下将使用该结构的所有字段，但指定primary.key.fields属性允许您从标头中选择字段的子集作为键。

SQL Server 标识插入

• 每个数据库以不同的方式处理将值插入到基于身份的列中。对于 SQL Server，这需要在插入之前显式启用 IDENTITY_INSERT，然后在插入之后禁用此功能。在 Debezium 2.4 中，Debezium JDBC 接收器连接器在目标数据库中提供了对此的支持。
• 为了利用基于身份的插入，必须使用名为 dialect.sqlserver.identity.inserts 的新的基于方言的属性来配置 JDBC 接收器连接器，该属性可以设置为 true 或 false。默认情况下，此功能设置为 false，如果您希望插入基于身份的列，则必须启用该功能。

启用后，所有插入和更新插入操作将按如下方式包装：

SET IDENTITY_INSERT <table-name> ON;
<the insert or upsert statement>
SET IDENTITY_INSERT <table-name> OFF;

九、Spanner

等待初始化任务超时

• 由于某些条件，Spanner 连接器在初始化期间可能无法从 START_INITIAL_SYNC 状态前进。经过 Nancy Xu 的调查，引入了一个新的配置选项来提供可配置的超时。这可以通过将connector.spanner.task.await.initialization.timeout 设置为所需的毫秒数来完成。

GKE 工作负载身份支持

• Google Kubernetes Engine (GKE) 支持身份工作负载，使您可以使用比传统的基于 JSON 的密钥更安全的身份验证机制。在 Debezium 2.4 中，当未显式设置 JSON 密钥时，Spanner 连接器现在将自动默认为 GKE 工作负载身份验证。

十、用户界面

连接器指标

• Debezium UI 项目允许您使用基于 Web 的界面轻松地将任何 Debezium 连接器部署到 Kafka Connect 上。此版本通过在主连接器列表视图上包含多个连接器指标来改进界面。

十一、偏移编辑器示例

• 用户经常出于各种原因表达需要操纵连接器偏移。如果您使用 Debezium Server，这对于那些可能不熟悉 Kafka 的 CLI 工具或 Java 的人来说通常会非常困难。现在可以使用编辑器从命令行或基于 Web 的界面操作偏移量。

具体实现请参考博主下面这篇技术文章：

• Debezium系列之：Debezium Server Offset编辑器

十二、Debezium生产环境大规模应用实战系列文章汇总

更多Debezium实际应用的技术文章可以阅读博主Debezium技术专栏：

• Debezium生产环境大规模应用实战系列文章汇总专栏