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

一、重大改变

1.MySQL

MySQL驱动程序已更新至版本8.3.0，该驱动程序与MySQL 5.x不兼容。如果您仍需要使用较旧的 MySQL 版本，请在安装后将驱动程序降级到与您的数据库兼容的版本。

2.MongoDB

MongoDB 连接器不再支持副本集模式 (DBZ-7260)。该功能已在多个版本中被弃用，并且 Debezium 2.x 正在进行工作以实现此目标。如果您使用的是replica_set模式，则在使用Debezium 2.6+时需要进行调整。

3.SQL Server

首次部署连接器时，SQL Server 连接器并未捕获所有架构，而是仅根据配置的包含列表中定义的表捕获架构。这是一个错误，当用户期望新表的架构已存在于架构历史记录主题中时，可能会阻止用户轻松地将新表添加到连接器。连接器现在正确支持 store.only.captured.tables.ddl 配置选项。

对于现有连接器部署，如果您没有专门设置架构历史记录主题的 store.only.captured.tables.ddl 属性，连接器将开始捕获数据库中所有相关表的架构更改。如果您想防止这种情况并保留之前的行为，则需要通过添加值为 true 的 schema.history.internal.store.only.captured.tables.ddl 来调整连接器配置。

4.Oracle

在旧版本的 Debezium 中，用户需要手动安装 ojdbc8.jar JDBC 驱动程序。在 2.6 中，连接器现在将 Oracle JDBC 驱动程序与连接器捆绑在一起，因此不再需要手动安装。

我们还将驱动程序更新到版本 21.11.0.0，请确认升级到 Debezium 2.6后您没有多个版本。

5.Vitess

以前版本的连接器使用的任务配置格式可能会破坏 Kafka Connect 集群的稳定性。为了解决该问题，Debezium 2.6 引入了一种与以前的格式不兼容的新配置格式。升级时，您可能会遇到 NullPointerException 和错误，指示连接器无法实例化任务，因为它包含无效的任务配置。

如果您遇到此问题，请删除并使用与以前相同的名称和配置重新创建连接器。连接器将启动并重新使用上次使用相同名称存储的偏移量，但不会重新使用旧的任务配置，从而避免启动失败。

Vitess 连接器之前使用 BEGIN 消息的时间戳作为源时间戳。这已更改为使用 COMMIT 时间戳来反映其他连接器的行为。

6.Container Images

connect-base 容器映像中 MAVEN_DEP_DESTINATION 环境变量的处理已更改，该容器映像是 debezium/connect 的基础。它不再用于下载所有依赖项，包括连接器，而仅用于通用 Maven Central 位于的依赖项。如果您使用依赖于此环境变量的自定义映像，则您的映像构建步骤可能需要修改。

二、新功能和改进

1.用于 iSeries 连接器的 Db2

Debezium 2.6 引入了一个全新的连接器，供 IBM 粉丝使用 IBM iJournal 系统从 Db2 iSeries/AS400 传输更改。此次合作是社区多年的开发成果，我们很高兴社区允许将其在 Debezium 的保护下进行分发。

可以使用以下坐标从 Maven Central 获取新连接器或直接下载。

<dependency>
    <groupId>io.debezium</groupId>
    <artifactId>debezium-connector-ibmi</artifactId>
    <version>2.6.0.Beta1</version>
</dependency>

2.Java 17 现在的编译时要求

Debezium 3.0 将于今年秋季晚些时候推出，将再次将 Java 基线要求从 Java 11 转移到 17，以使用 Debezium。为了准备今年晚些时候的 Debezium 3，我们将把 Debezium 2.6 和 2.7 的编译时基线转变为需要 Java 17。

如果您是 Debezium 用户，并且使用 Debezium 连接器，则不需要您执行任何操作。您现在可以继续使用 Java 11，不会有任何问题，因为 Debezium 3 将在今年晚些时候需要 Java 17。

如果您正在开发 Debezium 连接器，Java 17 现在是编译 Debezium 源代码的基准。如果您一直在使用 Java 17，则您不应该采取任何操作。如果您之前使用的是 Java 11，则需要迁移到 Java 17 才能从源代码进行编译。

如果您使用 Debezium Quarkus Outbox Extension（不是 Outbox SMT），由于 Quarkus 3.7+ 正在转向 Java 17 作为其基准，Debezium Quarkus Outbox Extension 现在将需要 Java 17 作为运行时和编译时的基准。

我们预计这种过渡对于大多数用户来说基本上是无缝的，因为此时这对 Debezium 连接器或 Debezium 服务器的运行时间绝对不会产生影响。

3.异步嵌入式引擎

如果您是第一次听说嵌入式引擎，Debezium 附带了三种运行 Debezium 连接器的方法。最常见的是在 Kafka Connect 上部署 Debezium，而第二常见的是使用 Debezium Server，这是 Debezium 连接器的只读运行时。然而，还有第三个选项，称为嵌入式引擎，它是 Debezium 在其测试套件内部使用的，它是 Debezium Server 的基础，旨在提供一种将 Debezium 连接器嵌入到您自己的应用程序中的方法。该嵌入式引擎被各种外部贡献者和框架使用，最值得注意的是 Apache Flink 严重依赖嵌入式引擎来实现基于 Debezium 的 CDC 连接器。

Debezium 2.6 最大、最重要的新功能之一是我们在此 alpha 版本中首次推出的异步嵌入式引擎。这个新的异步版本是 Debezium Server 和嵌入 Debezium 的未来的基础。这一变化侧重于几个关键目标和举措：

• 如果连接器支持多个任务，则为给定连接器运行多个源任务
• 在专用线程中运行耗时的代码（转换或序列化）
• 通过禁用事件调度顺序来提高性能
• 提供虚拟线程和委托给外部工作人员等未来技术优势
• 与 Debezium Operator for Kubernetes 和 Debezium UI 更好地集成
• 与 Debezium Server 的 Quarkus 无缝集成

这个新的异步模型不包括或不关注以下内容：

• 在连接器的主捕获循环内实现并行化
• 从 Kafka Connect 中删除任何依赖项
• 添加对每个引擎部署多个源连接器的支持
• 添加对接收器连接器的支持

即使连接器是单线程且不支持多个任务，使用嵌入式引擎或 Debezium 服务器的连接器部署也可以利用新的异步模型。均匀分派期间的大部分时间都花在转换和序列化阶段，因此在这些阶段使用新的专用工作线程可以提高吞吐量。

对于想要开始使用新的异步嵌入式引擎的开发人员，debezium 嵌入式工件中现在包含一个名为 io.debezium.embedded.async 的新包，该包包含利用此新实现的所有相关组件。可以使用构建器模式以与串行版本类似的方式构建异步模型，如下所示。

final DebeziumEngine engine = new AsyncEngine.AsyncEngineBuilder()
    .using(properties)
    .notifying(this::changeConsumerHandler)
    .build();

4.新的统一快照模式

快照过程是每个连接器生命周期不可或缺的一部分，它负责收集数据存储中存在的所有历史数据并将其发送到目标系统（如果需要）。对于使用多种连接器类型的 Debezium 用户，我们知道跨连接器具有不同的快照模式有时可能会令人困惑。所以这个改变就是为了解决这个问题而设计的。

对于许多可能已经尝试或安装 Debezium 2.6 预发行版的人来说，您已经在使用统一快照 SPI，因为它最初被设计为直接替换，不需要任何更改。此版本完成了 MongoDB 和 DB2 的工作。

在这些变化中，最值得注意的包括以下内容：

• 所有快照模式均可用于所有连接器，但不包括仅针对 MySQL 的“从不”模式。这意味着以前可能不支持快照模式（例如when_needed）的连接器现在可以在连接器识别出有必要时使用此模式重新拍摄快照。
• schema_only_recovery 模式已被弃用并被recovery模式取代。
• schema_only 模式也已被弃用并被 no_data 取代。

所有已弃用的模式在今年晚些时候的 Debezium 3 之前都将保持可用。这为用户提供了大约六个月的时间来提前调整脚本、配置和流程。

5.添加了新的匹配集合 API

该团队正在进行的任务之一包括将 Debezium UI 的后端迁移到主 Debezium 存储库。这样做的独特好处之一是我们可以识别连接器的运行时和 UI 之间存在代码重叠的位置，并开发接口契约来公开此共享数据。

对 RelationalBaseSourceConnector 合约进行了调整，并引入了一种新方法来返回与连接器的特定配置相匹配的表名称列表。任何实现此抽象基类的连接器都需要实现此新方法。

6.源事务id变化

所有 Debezium 更改事件都包含一个称为源信息块的特殊元数据块。这部分事件负载负责提供有关更改事件的元数据，包括更改的唯一标识符、更改发生的时间、更改引用的数据库和表，以及有关更改的事务的事务元数据。

在 Debezium 2.6 中，将不再提供源信息块中的 transaction_id 字段，除非该字段填充了值。这不会给用户带来任何问题，因为仅当连接器配置为 Provide.transaction.metadata 设置为 true 时，才会填充此字段。

如果您的工具期望源信息块的 transaction_id 字段存在（尽管它是可选的），则您将需要调整该行为，因为除非填充，否则该字段将不再存在。

7.提高了事件时间戳精度

Debezium 2.6 引入了社区要求的新功能，以提高更改事件中时间戳的精度。用户现在会注意到添加了 4 个新字段，其中两个位于信封级别，两个位于源信息块中，如下所示：

{
  "source": {
    ...,
    "ts_us": "1559033904863123",
    "ts_ns": "1559033904863123000"
  },
  "ts_us": "1580390884335451",
  "ts_ns": "1580390884335451325",
}

包络值将始终提供微秒 (ts_us) 和纳秒 (ts_ns) 值，而如果源数据库不提供该精度级别，则源信息块可能具有被截断为较低精度的微秒和纳秒精度值。

8.范围密钥/信任 - MongoDB 的存储支持

Debezium 支持安全连接；但是，MongoDB 要求将密钥/信任存储配置作为 JVM 进程参数提供，这对于云等环境来说不太理想。作为协调如何跨连接器指定安全连接配置的第一步，Debezium 2.6 for MongoDB 现在支持在连接器配置中指定作用域密钥/信任存储配置 (DBZ-7379)。

MongoDB 连接器现在包含以下新配置属性：

• mongodb.ssl.keystore：指定 SSL 密钥库文件的路径。
• mongodb.ssl.keystore.password：指定用于打开和访问 mongodb.ssl.keystore 提供的 SSL 密钥库的凭据。
• mongodb.ssl.keystore.type：指定 SSL 密钥库文件类型，默认为 PKC512。
• mongodb.ssl.truststore：指定 SSL 信任库文件的路径。
• mongodb.ssl.truststore.password：指定用于打开和访问 mongodb.ssl.truststore 提供的 SSL 信任库的凭据。
• mongodb.ssl.truststore.type：指定 SSL 信任库文件类型，默认为 PKC512。

9.MongoDB UUID 密钥支持增量快照

作为 Debezium for MongoDB 连接器增量快照流程的一个小改进，Debezium 2.6 添加了对 UUID 数据类型的支持，允许该数据类型像其他数据类型一样在增量快照流程中使用。

10.MongoDB 图像后更改

• MongoDB 连接器的事件负载可以配置为包含更新中更改的完整文档。连接器之前对如何获取完整文档作为变更流的一部分做出了固执己见的选择；然而，这种行为与我们在所有用例中的预期并不相符。
• Debezium 2.6 引入了一个新的配置选项 capture.mode.full.update.type，允许连接器显式控制如何处理变更流的完整文档查找。该选项的默认值是lookup，这意味着数据库将进行单独的查找以获取完整文档。如果您使用 MongoDB 6+，您还可以选择使用 post_image 来依赖 MongoDB 更改流的后期映像支持。

11.PostgreSQL 的增量快照行值构造函数

PostgreSQL 驱动程序支持使用 ROW() 函数的称为行值构造函数的 SQL 语法。这允许查询在使用具有合适索引的多列主键时以更有效的方式表达谓词条件。增量快照过程是使用 ROW() 函数的理想选择，该过程涉及发出一系列 select SQL 语句以分块获取数据。理想情况下，每个语句（也称为块查询）应该尽可能高效，以最大限度地减少这些查询的成本开销，从而最大限度地提高主题的 WAL 更改的吞吐量。

不需要进行任何具体更改，但对 PostgreSQL 增量快照发出的查询已进行调整以利用此新语法，因此使用增量快照的用户应该会看到性能改进。

对于一个简单的表，使用的旧查询的示例可能如下所示：

SELECT *
  FROM users
 WHERE (a = 10 AND (b > 2 OR b IS NULL)) OR (a > 10) OR (a IS NULL)
 ORDER BY a, b LIMIT 1024

新的实现使用 ROW() 函数构造此查询，如下所示：

SELECT *
  FROM users
 WHERE row(a,b) > row(10,2)
ORDER BY a, b LIMIT 1024

12.SQL Server 查询改进

Debezium SQL Server 利用名为 fn_cdc_get_all_changes… 的通用 SQL Server 存储过程来获取给定表的所有相关捕获的更改。此查询执行多个联合，并且仅从联合子查询之一返回数据，这可能效率低下。

Debezium 2.6 for SQL Server 引入了一个新的配置属性 data.query.mode，可用于影响连接器将使用哪种特定方法来收集有关表更改的详细信息。与旧版本相比，默认值保持不变，使用值function委托给上述存储过程。可以使用名为 direct 的新选项直接在连接器内构建查询，以更有效地收集更改。

13.Oracle Infinispan 缓存改进

Debezium Oracle 连接器维护所有正在进行的事务的缓冲区，并且可以使用 Infinispan 在堆外分配该缓冲区。有时，用户配置指定如果正在进行的事务持续时间超过指定的毫秒数，则缓冲区可以放弃或丢弃该事务。这意味着交易将被遗忘并且不会被连接器发出。

为了改进与 Grafana 和 Prometheus 等框架的指标集成，添加了一个新的 JMX 指标 AbandonedTransactionCount，以跟踪连接器在运行时放弃的事务数量。

14.Oracle 使用 LogMiner 重做每个事件的 SQL

我们改进了 Oracle 连接器的插入、更新和删除事件结构，以选择性地包含由 LogMiner 在源信息块中重建的 SQL。此功能是一项仅限选择加入的功能，您必须启用该功能，因为这很容易使现有事件负载的大小增加一倍以上。

要允许将 REDO SQL 作为更改事件的一部分包含在内，请添加以下连接器配置：

"log.mining.include.redo.sql": "true"

启用该选项后，源信息块包含一个新字段redo_sql，如下所示：

"source": {
  ...
  "redo_sql": "INSERT INTO \"DEBEZIUM\".\"TEST\" (\"ID\",\"DATA\") values ('1', 'Test');"
}

由于 LogMiner 重构与 CLOB、BLOB 和 XML 数据类型相关的 SQL 的方式，此功能无法在 lob.enabled 设置为 true 的情况下使用。如果在 lob.enabled 设置为 true 的情况下添加上述配置，连接器将启动并显示有关此错误配置的错误。

15.Oracle LogMiner 事务缓冲区改进

使用 LogMiner 时添加了新的事务注册延迟策略。该策略有效地延迟了缓冲区中事务记录的创建，直到我们观察到该事务的第一个捕获的更改。

对于使用Infinispan缓存或启用了lob.enabled的用户，由于连接器这两种模式下具体操作的处理方式，无法使用此延迟策略。

延迟交易注册有很多好处，其中包括：

• 减少事务缓存的开销，特别是在高并发事务场景下。
• 避免长时间运行的事务没有连接器捕获的任何更改。
• 应有助于在特定场景中更有效地推进偏移中的低水印 SCN。

我们正在研究如何在未来的版本中为基于 Infinispan 的用户探索这一变化；但是，由于 lob.enabled 与 LogMiner 配合使用的性质，该功能对于该用例来说是不可能的。

16.Oracle LogMiner 混合挖矿策略

Debezium 2.6 还引入了一种名为 hyrid 的新 Oracle LogMiner 挖掘策略，可以通过将配置属性 log.mining.strategy 设置为 Hyrid 值来启用该策略。这种新策略旨在支持默认挖掘策略的所有模式演化功能，同时利用在线目录策略的所有性能优化。

online_catalog 策略的主要问题是，如果挖掘步骤在同一挖掘步骤中观察到模式更改和数据更改，则 LogMiner 无法正确重建 SQL，这将导致表名称为 OBJ# xxxxxx 或列表示为 COL1、COL2 等。为了在使用在线目录策略时避免这种情况，建议用户以锁步模式执行模式更改，以避免同时观察模式更改和数据更改的挖掘步骤；然而，这并不总是可行的。

新的混合策略的工作原理是在数据库级别跟踪表的对象 ID，然后使用该标识符从 Debezium 的关系表模型中查找与该表关联的模式。简而言之，这使得 Debezium 能够完成 Oracle LogMiner 在这些特定的极端情况下无法完成的任务。表名将从关系模型的表名中获取，列将按列位置映射。

不幸的是，Oracle 没有提供一种方法来重建 CLOB、BLOB 和 XML 数据类型的失败 SQL 操作。这意味着新的混合策略无法使用将 lob.enabled 设置为 true 的配置进行配置。如果连接器使用混合策略启动并将 lob.enabled 设置为 true，则连接器将无法启动并报告配置失败。

17.OpenLogReplicator 的 XML 支持

Debezium for Oracle 连接器支持与 OpenLogReplicator 的连接，允许 Oracle 用户直接从事务日志流式传输更改。 OpenLogReplicator 的最新版本 1.5.0 版本添加了对 XML 列类型的支持。

要开始使用 OpenLogReplicator 传输 XML，请将 OpenLogReplicator 进程升级到 1.5.0 并重新启动复制器进程。请注意，如果您想要流式传输基于二进制的 XML 列数据，则需要在 OpenLogReplicator 配置中启用此功能。

18.Informix 将 LSN 附加到事务标识符

Informix 数据库仅在存在并发事务时增加事务标识符，否则对于顺序事务，该值保持相同。对于可能想要在后处理步骤中利用事务元数据来排序更改事件的用户来说，这可能会很困难。

Debezium 2.6 for Informix 现在会将日志序列号 (LSN) 附加到事务标识符，以便用户可以轻松地根据事务元数据对更改事件进行排序。事务标识符字段现在将使用格式 :。此更改会影响交易元数据事件以及更改事件的源信息块，如下所示：

交易开始事件

{
  "status": "BEGIN",
  "id": "571:53195829",
  ...
}

交易结束事件

{
  "status": "END",
  "id": "571:53195832",
  ...
}

变更事件

{
  ...
  "source": {
    "id": "571:53195832"
    ...
  }
}

19.支持 Spanner NEW_ROW_AND_OLD_VALUES 值捕获类型

Google Spanner 的值捕获类型负责控制变更流如何表示事件流中的变更数据，并在构建变更流时进行配置。

Spanner 引入了一种名为 NEW_ROW_AND_OLD_VALUES 的新值捕获模式，该模式负责在任何列发生更改时捕获跟踪列的所有值（包括已修改的和未修改的）。这种新模式是对 NEW_ROW 的改进，因为它还包括旧值的捕获，使其与您通常在其他 Debezium 连接器中观察到的情况保持一致。

20.新的基于任意的有效负载格式

虽然用户通常使用基于 Json、Avro、Protobufs 或 CloudEvents 的序列化，但可能有理由使用更简单的格式。感谢 DBZ-7512 的社区贡献，Debezium 可以配置为使用两种新格式，称为简单字符串和二进制。

简单字符串和二进制格式是使用 debezium.format 配置在 Debezium 服务器中配置的。对于 simplestring，有效负载将作为单个 STRING 数据类型序列化到主题中。对于二进制文件，有效负载将使用 byte[]（字节数组）序列化为 BYTES。

21.Debezium 服务器的 TRACE 级别日志记录

Debezium Server 是 Debezium 源连接器的现成运行时，它使用 Quarkus 框架来管理源和接收器部署。大多数 Debezium Server 用户都知道谁曾提出问题或错误，我们经常要求提供 TRACE 级别的日志，但这通常被证明很困难，因为它需要完全重建 Debezium Server，因为最低日志记录级别是构建时的Quarkus 中的配置。

在 Debezium 2.6.0.CR1 版本及更高版本中，不再需要此操作。默认情况下，构建时配置已调整为包括 TRACE 日志记录级别，因此以后用户只需将日志级别设置为 TRACE 并重新启动 Debezium Server 即可获取日志。

22.Google PubSub 订购密钥支持

Debezium Server Google PubSub 接收器适配器在 Debezium 2.6 中收到了一个小更新。如果您正在流式传输具有外键关系的更改，您可能想知道是否可以指定排序键以便维护外键约束。

Debezium 2.6 为 Google PubSub 接收器适配器引入了一个新的可配置属性 ordering.key，它允许接收器适配器使用事件连接器配置中外部提供的排序键，而不是使用基于事件键的默认行为。

23.CloudEvents 架构名称自定义

使用模式注册表时，需要使用名称注册事件模式，以便可以在以后通过管道查询时查找它们。因此，当将 CloudEvents 格式的消息与架构注册表配对时，同样适用，并且在 Debezium 2.6 中，您可以显式控制名称的注册方式。

默认情况下，CloudEvent 消息的架构将由转换器自动生成。但是，如果自动生成的架构名称不够，您可以通过指定 dataSchemaName 来调整配置，可以将其设置为生成（默认行为）或标头，以直接从指定的事件标头字段中提取架构名称。

24.时间戳转换器改进

Debezium 在 Debezium 2.4 中发布了新的 TimezoneConverter，允许用户定位特定时区并将传出负载时间值转换为该目标时区。最初的实现被明确限制为允许在有效负载的前后部分内进行值转换；该转换器现在可用于转换元数据中的其他基于时间的字段，例如源信息块中的 ts_ms。

在运行连接器的 JVM 使用与数据库不同的时区的情况下，此更改有助于改进滞后指标计算，并且信封 ts_ms - 源 ts_ms 的计算会导致由时区引起的差异。通过使用 TimezoneConverter 转换元数据字段，您可以轻松计算这两个字段之间的滞后，而不会受到时区干扰。

25.信号表水印元数据

增量快照过程需要一个信号表来写入打开/关闭标记，以协调更改边界与事务日志中记录的数据，除非您使用 MySQL 的只读风格。在某些情况下，用户希望能够跟踪窗口时间段，了解窗口何时打开和关闭。

从 Debezium 2.6 开始，信号表中的数据列将填充时间窗口详细信息，允许用户获取窗口何时打开和关闭。下面显示了两个信号标记各自的数据列的详细信息：

窗口打开标记

{"openWindowTimestamp": "<window-open-time>"}

窗口关闭标记

{"openWindowTimestamp": "<window-open-time>", "closeWindowTimestamp": "<window-close-time>"}

26.Debezium 服务器的 TRACE 级别日志记录

Debezium Server 是 Debezium 源连接器的现成运行时，它使用 Quarkus 框架来管理源和接收器部署。大多数 Debezium Server 用户都知道谁曾提出问题或错误，我们经常要求提供 TRACE 级别的日志，但这通常被证明很困难，因为它需要完全重建 Debezium Server，因为最低日志记录级别是构建时的Quarkus 中的配置。

在 Debezium 2.6+ 版本中，不再需要这样做。默认情况下，构建时配置已调整为包括 TRACE 日志记录级别，因此以后用户只需将日志级别设置为 TRACE 并重新启动 Debezium Server 即可获取日志。

27.Cassandra 可配置分区模式

当 Debezium Cassandra 连接器读取提交日志时，事件将按顺序处理并添加到队列中。如果存在多个队列，则事件将根据提交日志文件名的哈希在这些队列之间分配。这导致事件可能以非时间顺序发出的情况。

在 Debezium 2.6 中，Cassandra 连接器的哈希算法现在使用分区列名称来解析插入的队列索引。这应该提供更稳定的插入顺序，以便事件以正确的顺序发出。

添加了一个新的配置选项来选择加入此新行为。 Debezium 用户可以将新的配置属性 event.order.guarantee.mode 添加到partition_values 以利用这种新模式。默认情况下，该属性使用默认值 commitlog_file 保留旧行为。

三、Debezium技术总结

更多Debezium技术请参考：

• Debezium技术专栏