增量快照大约在两年前的 Debezium 1.6 中首次推出，并且在社区中一直非常受欢迎，用于处理各种重新快照用例。但是，在某些用例中，读事件与创建、更新和删除事件的相互交织可能不是理想的，甚至不被某些消费者应用程序支持。对于这些用例，Debezium 2.4 引入了临时阻塞快照。

临时阻塞快照的工作方式与临时增量快照非常相似；然而，有一个主要区别。快照仍然通过发送信号给 Debezium 来触发；然而，当连接器处理信号时，主要区别在于流式传输被暂停，直到快照过程运行完毕。这意味着您将不会收到一系列读事件与创建、更新或删除事件交织在一起。这也意味着我们将以类似于传统快照的方式处理快照，因此吞吐量通常会比增量快照更高。

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

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

Debezium 的新通知子系统提供了一种简单的方式，可以将第三方工具和应用程序与 Debezium 集成，以洞察正在进行的变更数据捕获过程，超出了传统的 JMX 方法。在 2.4 版本中，通知子系统现在增加了通知初始快照状态的能力（DBZ-6416）。

初始快照通知将以 Initial Snapshot 的 aggregatetType 发出，并包含一个 type 字段，该字段显示快照的当前状态。可能的值包括：STARTED、ABORTED、PAUSED、RESUMED、IN_PROGRESS、TABLE_SCAN_COMPLETED 和 COMPLETED。

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

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

所有通知事件现在都将包含一个时间戳（DBZ-6793）。

通常，当被 JDBC 连接器等目标连接器消费时，列名直接映射到字段名，反之亦然。但是，在某些情况下，序列化技术（如 Avro）对字段命名约定有非常严格的规则。当数据库表中的列名与序列化规则的命名约定冲突时，Debezium 会在事件中重命名该字段，使其符合序列化的规则。这通常意味着字段会被加上下划线，或者无效字符会被下划线替换。

这可能对某些类型的目标（如 JDBC 目标连接器）造成问题，因为目标无法轻松推断目标表中原始列名，也无法在事件字段名和列名不同时进行充分映射。这通常意味着用户必须在目标端使用转换链来重建事件字段，使其命名代表源。

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

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

Debezium 2.4 现在附带了一个全新的时区转换器，该转换器允许您精细控制发出的事件中哪些时间列可以从 UTC 转换为您管道所需的任何时区。要开始使用此新转换器，请将以下基本配置添加到您的连接器中。

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

在上面的示例中，第一项将转换 created_at 字段，其中源表名是 customers，而后者将转换 updated_at 字段，其中主题名是 customers。此外，您还可以使用 exclude.fields 排除字段的转换，以便将转换应用于除特定子集以外的所有字段。

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

您可以在文档中找到有关此新转换器的更多信息，我们非常希望听到您的反馈。

监视单个数据库或集合时不再需要集群范围的权限（DBZ-6182）。

Debezium 2.4 现在提供了一种控制变更流管道聚合顺序的方法。这对于正在聚合可能导致管道问题的特定文档（如大型文档）至关重要。

默认情况下，连接器先应用 MongoDB 内部管道过滤器，然后应用用户构造的过滤器；然而，这可能导致大型文档进入管道，并且如果文档超过内部 16Mb 限制，MongoDB 可能会抛出错误。在这些用例中，连接器现在可以配置为首先应用 cursor.pipeline 定义的用户阶段来过滤此类用例，以避免管道因 16Mb 限制而失败。

要实现这一点，只需将以下配置应用于连接器。

有关更多详细信息，请参阅文档。

在特定环境（如 AWS）中，您需要使用 AWS IAM 基于角色的身份验证来连接到 MongoDB 集群；然而，这需要使用 AWS_CREDENTIAL_PROVIDER 设置属性。此提供程序负责创建会话并提供凭据。

为了在这些环境中更无缝地集成，添加了一个新的配置属性 mongodb.authentication.class，允许您直接在连接器配置中定义凭据提供程序类。如果您需要使用此类提供程序配置，现在可以在连接器配置中添加以下内容。

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

有关更多信息，请参阅文档。

为 MongoDB 添加了一个新的配置属性 filtering.match.mode，允许指定如何处理过滤。此属性可以设置为 regex 或 literal（DBZ-6973）。

MongoDB 7.0 于上个月发布，Debezium 2.4 支持 MongoDB 7。

如果您想将您的环境升级到 MongoDB 7，您可以轻松做到，因为 Debezium 2.4+ 完全兼容新版本。如果您遇到任何问题，请告知我们。

自 Debezium 1.x 推出增量快照以来，在捕获数据库事务的并发更改的同时增量快照现有数据的过程一直是一个单线程活动。添加新功能时，通常会先关注基础，然后在此基础上进行构建，这正是 MongoDB 的情况。

在 Debezium 2.4 中，我们通过并行读取多个块，迈出了为 MongoDB 连接器的增量快照添加并行支持的第一步。这应该能够提高吞吐量，但以内存为代价，同时收集、排序和去重块数据。感谢Yue Wang 在DBZ-6518 中启动这项工作，这绝对是我们将在未来的 Debezium 版本中为关系型连接器探索的内容。

从连接字符串中读取偏好（DBZ-6468, DBZ-6578）。

支持 TC MongoDB 部署的身份验证（DBZ-6596）。

为了在 AWS 上使用 IAM 身份验证，需要一个特殊的 MySQL 驱动程序来提供此类功能。通过 Debezium 2.4，您现在可以提供此特定驱动程序的引用，连接器将使用该驱动程序而不是连接器附带的默认驱动程序。

例如，要使用 AWS 上的 IAM 身份验证进行连接，需要进行以下配置。

database.jdbc.driver 指定了连接器应加载并用于与 MySQL 数据库通信的驱动程序。database.jdbc.protocol 是一个辅助配置属性，可能并非在所有情况下都需要。它默认为 jdbc:mysql，但由于 AWS 需要 jdbc:mysql:aws，因此允许您在配置中指定此派生。

我们很乐意听到您的反馈，以及类似的功能是否可能在其他场景中有用。

感谢 Harvey Yue 的贡献（DBZ-6472），MySQL 连接器将在其快照阶段使用并行化来生成 Schema 事件。这应该能提高捕获数据库中大量表 Schema 的整体性能。我们计划研究如何将此功能扩展到其他关系型连接器。

PostgreSQL 于一周多前发布了 PostgreSQL 16 的即时版本，我们很高兴地宣布 Debezium 2.4 将支持该版本。

TimescaleDB 是一个开源的时间序列数据库，基于 PostgreSQL。这意味着支持 TimescaleDB 的大部分功能直接来源于现有的 PostgreSQL 连接器；然而，TimescaleDB 的某些方面，如块 (chunks)、超表 (hypertables) 和聚合 (aggregates) 则不是。

因此，如果您想开始使用 Debezium 2.4 和 TimescaleDB，集成需要结合 PostgreSQL 连接器和一个新的 TimescaleDb 单消息转换 (SMT)。这两个结合提供了从 TimescaleDB 环境流式传输更改的能力，并根据块、超表和聚合生成适当的表名。

TimescaleDb 转换器作为 io.debezium.connector.postgresql.transforms.timescaledb 可用，它负责在处理块、超表和聚合时调整最终的主题名称。此外，此转换器会将元数据头添加到更改事件中，以便您了解原始块名称、块表、超表 Schema 和表名。

Oracle 连接器支持三种不同的缓冲技术，一种基于 JVM 堆，另外两种基于使用 Infinispan 的堆外存储。在使用 Infinispan 时，您可以选择使用远程集群，其中缓存通过远程连接存储和管理，或者使用嵌入式集群，其中集群由连接器本身在本地管理。

在使用远程 Infinispan 集群时，集群配置是在 Infinispan 安装本身中完成的，这通常被称为全局或集群配置。然而，在使用嵌入式 Infinispan 集群时，Debezium 仅使用嵌入式集群的默认配置，这可能并不总是为每个环境提供所有必需的行为。

Debezium 2.4 引入了一个新的配置属性 log.mining.buffer.infinispan.cache.global。此属性允许指定 Infinispan “全局”或“集群”配置的 XML 配置。

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

Oracle 连接器为 LogMiner 提供了大量的指标，包括 OldestScn 指标，表示连接器事务缓冲区中最老的系统更改号。这个 SCN 对于了解事务相对于当前系统更改号 CurrentScn 仍然缓冲了多远非常有用。然而，系统更改号仅仅是数字值，需要使用数据库函数调用才能知道更改何时发生。

从 Debezium 2.4 开始，连接器还将跟踪最旧系统更改号的年龄，提供一个名为 OldestScnAgeInMilliseconds 的新指标。此指标通过获取 OffsetScn 的时间戳，并计算该时间与指标查询时间之间的差值来计算，从而估算缓冲区中尚未提交或回滚的最旧事务的大致年龄（以毫秒为单位）。

如果您还有其他感兴趣的指标，请联系我们。

Debezium for Oracle 连接器传统上提供两个适配器，一个用于 Oracle XStream，另一个用于直接集成 Oracle LogMiner。虽然每个适配器都有其优点，并且在功能和对各种数据类型及用例的支持方面都非常成熟，但我们希望探索一种完全不同的捕获更改的方式。

Debezium 2.4.0.Beta2 引入了一个新的、实验性的 Oracle 摄入适配器，基于OpenLogReplicator。该适配器直接与 OpenLogReplicator 进程集成，以类似 XStream 实现作为 Oracle GoldenGate 客户端的方式创建更改事件。

OpenLogReplicator 是一个独立的进程，它必须运行在 Oracle 数据库服务器上，或者可以独立于数据库服务器运行，但需要通过 TCP/IP 与数据库进行直接通信，并直接读取 Oracle 重做日志和归档日志文件。OpenLogReplicator 也不提供任何预构建的二进制文件，因此代码必须直接从源代码构建，或者部署在可以远程通过文件共享访问数据库及其文件的容器镜像中。

一旦安装了 OpenLogReplicator，设置需要以下步骤：

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

当 OpenLogReplicator 配置完成后，您应该会看到 OpenLogReplicator 启动，并显示以下内容：

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

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

我们将在接下来的几周内发布另一篇博客文章，详细介绍 OpenLogReplicator，为最终发布做准备。在此期间，请随意尝试新的摄入方法，我们非常希望听到您的反馈。

Debezium 2.4 支持几种新的 Oracle 数据类型，包括 XML_TYPE 和 RAW（DBZ-3605）。支持 XML 需要两个新的 Oracle 依赖项：xdb 和 xmlparserv2。这些依赖项不可重新分发，因此它们默认不包含在连接器插件存档中，这与连接器的驱动程序类似。您必须像驱动程序依赖项一样，直接从 Maven Central 或 Oracle 获取它们。

此外，XML 的工作方式类似于 CLOB 和 BLOB 数据类型；因此，必须将连接器配置为 lob.enabled 设置为 true 才能摄入 XML 更改。我们很乐意听到您对这项新功能的反馈，因为它已经提出了很长一段时间。

数据库在一段时间内没有发生任何相关更改的情况并不少见，无论是由于不活动还是发生的更改根据配置对连接器不感兴趣。在这些情况下，至关重要的是连接器管理的偏移元数据在这些期间保持与偏移存储同步，以便连接器的重新启动能够按预期工作。

在 Debezium 2.4 中，如果 SQL Server 更改捕获循环未找到任何更改，或者发生的更改与连接器无关，则在启用心跳的情况下，连接器将继续发出心跳事件。这应该能提高在各种用例中偏移存储中偏移的可靠性。

Nicholas Fwang 添加了将更改事件 source 信息块中的值作为连接器配置属性 table.name.format 的一部分引用的功能。如果您想引用此类字段，只需在配置中使用 ${source.<field-name>} 即可，并将使用字段的值（DBZ-6595）。

Roman Kudryashov 贡献了从更改事件上定义的头中解析行主键的功能。要使用此新功能，请将连接器配置属性 primary.key.mode 指定为 record_header。如果头值是原始类型，您将需要定义一个 primary.key.fields 配置，就像事件记录键是原始类型一样。如果头值是 struct 类型，默认情况下将使用该结构的所有字段，但指定 primary.key.fields 属性允许您从头中选择一部分字段作为键（DBZ-6602）。

每个数据库处理向标识列插入值的方式都不同。对于 SQL Server，这需要在插入之前显式启用 IDENTITY_INSERT，并在之后禁用此功能。通过 Debezium 2.4，Debezium JDBC 目标连接器为目标数据库提供了此支持。

为了利用基于标识的插入，JDBC 目标连接器必须配置一个名为 dialect.sqlserver.identity.inserts 的新基于方言的属性，该属性可以设置为 true 或 false。默认情况下，此功能设置为 false，如果您希望插入到基于标识的列中，则必须启用它。

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

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

Google Kubernetes Engine (GKE) 支持身份工作负载，允许您使用比传统基于 JSON 的密钥更安全的身份验证机制。在 Debezium 2.4 中，当没有显式设置 JSON 密钥时，Spanner 连接器将自动默认为 GKE 工作负载身份验证。感谢laughingman7743 作为DBZ-6885 的一部分所做的努力。

Debezium UI 项目允许您使用基于 Web 的界面轻松地将任何 Debezium 连接器部署到 Kafka Connect。此版本改进了界面，在主连接器列表视图中包含了一些连接器指标。我们非常希望收到您对这一变化的反馈，并欢迎您对其他有用的指标提出建议（DBZ-5321）。

用户经常表达出于各种原因需要操作连接器偏移量的需求。对于不熟悉 Kafka 命令行工具或 Java（如果您使用 Debezium Server）的用户来说，这通常非常困难。感谢 Nathan Smit 的贡献（DBZ-6338），您现在可以使用编辑器从命令行或基于 Web 的界面来操作偏移量。

前往我们的示例存储库并按照 README.md 开始。