Debezium 2.5 引入了一个新的配置选项 schema.history.internal.redis.max.attempts，旨在限制在 Redis 数据库不可用时连接 Redis 数据库的重试次数，之前它是无限重试的。此新选项默认为 10，但可由用户配置。（DBZ-7120）。

Debezium 的通知子系统提供了一种简单的方式，可以将外部进程和应用程序与 Debezium 的特定任务集成，例如拍摄快照。在之前的版本中，初始快照的通知非常基础，仅提供快照开始、每个表开始和结束的时间，最后快照结束的详细信息。

最近一项作为 DBZ-6878 的一部分的贡献，扩展了此基本功能，以提供有关快照的增强详细信息。例如，IN_PROGRESS 通知将提供有关正在捕获哪些表以及当前哪个表处于进行中的其他详细信息，如下所示：

此外，另一个名为 TABLE_SCAN_COMPLETED 的初始快照通知也提供了类似的详细信息，如下所示：

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

在某些情况下，由于某些源数据库的工作方式，当 Debezium 连接器发出更改事件时，该事件可能会排除特定列类型的值。例如，PostgreSQL 中的 TOAST 列、Oracle 中的 LOB 列或 Oracle Exadata 中的 Extended String 列的值可能都会被排除。

Debezium 2.5 引入了 ReselectColumnsPostProcessor，它提供了一种从数据库表中重新选择一个或多个列并获取当前状态的方法。您可以配置后处理器来重新选择以下列类型：

配置 PostProcessor 的方式与配置 CustomConverter 或 Transformation 类似，不同之处在于它作用于可变 payload 的 Struct 而不是 SourceRecord。

引入了 incremental.snapshot.watermarking.strategy 属性，让用户可以选择在增量快照期间使用的水印策略。

insert_insert（旧行为）方法允许 Debezium 为快照期间的每个块在信号数据集合中创建两个条目，一个用于信号快照窗口的开启，另一个用于标记其关闭。

另一方面，使用 insert_delete 选项，会在窗口开始时为每个块在信号数据集合中写入单个条目。完成后，此条目将被移除，并且不会添加相应的条目来表示快照窗口的关闭。此方法有助于更有效地管理信号数据集合。

有关更多详细信息，请参阅您感兴趣的连接器的“连接器属性”部分。

Debezium 在近几个版本中对大型文档的处理进行了多项改进；然而，这些改进主要集中在处理 MongoDB 4 和 5 的用例。虽然这些改进无疑对这些旧版本有所帮助，但 MongoDB 社区在 MongoDB 6 中引入了一种方法，可以在数据库管道级别无缝处理此问题。

Debezium 2.5 的 MongoDB 连接器现在使用 $changeStreamSplitLargeEvent 聚合功能，该功能作为 MongoDB 6.0.9 的一部分引入。这避免了在处理超过 MongoDB 16MB 文档大小限制的文档时出现 BSONObjectTooLarge 异常。此新功能由 oversize.handling.mode 选项控制，该选项默认为 fail。如果您希望利用此新的、选择加入的功能，请调整此配置。（DBZ-6726）。

MySQL 社区于 2023 年 10 月底发布了新的创新版本 MySQL 8.2.0。此新版本已通过 Debezium 测试，我们很高兴地宣布我们正式支持此新的创新版本。（DBZ-6873）。

多个新的高精度时间戳字段已包含在多个 MySQL 复制事件中。例如，在 MySQL 8.0.1 中，GTID 事件添加了微秒分辨率的时间戳，用于指定事务在直接主库上提交的时间以及在原始主库上提交的时间。

Debezium 2.5 现在利用这些值，如果可用，将使用它们来填充 ts_ms 字段，如果不可用或您使用的是 8.0.1 之前的 MySQL 版本，则会回退到基于秒的精度。（DBZ-7183）。

在 PostgreSQL 16 中，您现在可以在备用服务器上定义复制槽。这提供了许多新选项，包括能够从副本而不是生产系统进行更改数据捕获，以进行负载分担，特别是在非常活跃的数据库中。

Debezium 2.5 现在支持连接到备用的 PostgreSQL 16 服务器并流式传输更改。（DBZ-7181）。

在 Debezium 的先前版本中，有一个单独的 Oracle 流式指标 bean，它公开了跨越所有三个流适配器的所有指标选项。这经常导致对哪个指标适用于哪个流适配器感到困惑，因此我们希望在这种情况下做出明确的区分。

在 Debezium 2.5 中，Oracle 流式指标 bean 已拆分为三个不同的实现，每个适配器类型一个。对于可观察性堆栈，此更改应该是完全透明的，除非您之前在另一个适配器类型上收集了一个指标。在这种情况下，您会发现该指标不再可用。

特别是对于 LogMiner 用户，一些指标已重命名，旧指标已被弃用。虽然您仍然可以在 Debezium 2.5 中使用旧指标名称，但这些指标计划在未来的 2.7+ 版本中移除。已弃用和重命名的指标如下：

Debezium 2.5 在快照和流式传输中统一了 LOB 行为。当 lob.enabled 设置为 false 时，将在快照期间明确包含不可用值占位符，以匹配流式传输的行为。

Debezium for SQL Server 通过读取数据库中称为捕获实例的更改来进行工作。这些实例可以根据用户的需求出现和消失，并且很难知道 Debezium 是否已完成给定捕获实例自身的捕获过程。

Debezium 2.5 通过发出新的名为 Capture Instance 的通知聚合来解决此问题，允许任何观察者了解 Debezium 何时不再使用某个捕获实例。此新通知包含各种连接器详细信息，包括连接器的名称以及开始、停止和提交 LSN 值。（DBZ-7043）。

SQL Server 2019 引入了指定特定列敏感性分类的能力，以提供对敏感数据的更好可见性和保护。不幸的是，Debezium 2.4 及更早版本附带的当前驱动程序不支持此功能。Debezium 2.5 引入了最新的 12.4.2 SQL Server 驱动程序，因此用户现在可以开箱即用地利用此功能。（DBZ-7109）。

Debezium 于 2023 年 3 月首次将 JDBC 接收器连接器引入作为 Debezium 2.2 的一部分。在过去的几个月中，此连接器经历了多次迭代，以提高其稳定性、功能集和功能。Debezium 2.5 在这些工作的基础上，引入了批量写入。（DBZ-6317）。

在先前的版本中，连接器单独处理每个主题事件；然而，新的批量写入支持模式会将事件收集到存储桶中，并使用尽可能少的事务边界将这些更改写入目标系统。此更改提高了连接器的吞吐量能力，并使与目标数据库的交互更加高效。

Debezium 2.5 引入了一项新的 JDBC 接收器功能，用户现在可以指定要包含或排除在目标数据库写入操作中的事件 payload 字段。此功能的工作方式与其他 Debezium 框架中的包含/排除组合方式相同，即这两个属性是互斥的。

例如，如果我们有一个简单的事件 payload，在主题 customers 中包含以下字段：

如果我们想避免将 address 字段写入目标数据库，而只将 id 和 name 字段写入目标表，我们可以使用此新功能来实现。这可以通过添加 field.include.list 或 field.exclude.list 属性来完成。

字段包含/排除的格式是 [<topic-name>:]<field-name>，其中 topic-name 是可选的，如果您想避免为所有事件写入 address 字段，则可以省略。有关更多详细信息，请参阅 JDBC 接收器连接器配置文档。

Kubernetes 的 Debezium Server Operator 在 Debezium 2.5 的此预览版本中得到了积极改进。一些改进包括：

随着我们继续改进 Kubernetes 的 Debezium Server Operator，我们很乐意听取您的反馈。

在 Debezium 的先前版本中，无法使用不同于预定义名称的服务账户。这使得用户过程有点麻烦，因为虽然您可以单独向此预定义账户授予角色和授权，但这意味着您需要使用此预定义服务账户，而不是您可能希望使用的服务账户。

Debezium 2.5 简化了此过程，允许您现在使用自己的自定义服务账户。（DBZ-7111）。

Debezium Server Kinesis 用户将很高兴地注意到，Debezium 2.5 的接收器适配器在可靠性方面得到了一些改进。Kinesis 接收器现在最多会重试失败记录的传递 5 次，然后适配器才会触发失败。这应该可以提高接收器适配器的传递可靠性，并帮助处理批量的更改可能会导致接收器端点过载的情况。（DBZ-7032）。

在 Debezium Server 的早期版本中，用户可以指定一个固定的分区 ID 将所有更改流式传输到一个分区，或者提供一个将设置在所有批处理操作上的静态分区键，这最终会导致所有更改流式传输到同一目标分区。在某些情况下这可能很有用，但它更多地导致了下游处理的性能问题。

Debezium 2.5 调整了此行为以提高性能。默认情况下，当未定义 partitionid 或 partitionkey 时，EventHub 接收器将使用轮询技术将事件发送到所有可用分区。可以通过指定 partitionid 将事件强制放入单个固定分区。或者，可以提供 partitionkey 来提供一个固定的分区键，用于将所有事件路由到特定分区。

如果需要其他分区路由要求，现在可以结合使用 PartitionRouting SMT 来完成这些任务。有关更多详细信息，请参阅 Event Hubs 文档。

RabbitMQ 在 3.9 版本中引入了 Streams，它利用了一种快速高效的协议，可以与 AMQP 0.9.1 结合使用，以支持大型扇出、重放和时间旅行，以及高吞吐量的大型数据集。Debezium 2.5 利用了此新的 Streams 实现，通过引入一个新的原生 Streams 实现。（DBZ-6703）。要开始使用此新实现，请按如下方式配置 Debezium Server 接收器：

此外，如果您需要将任何其他连接参数传递给 RabbitMQ 连接，您可以通过在配置中添加 debezium.sink.rabbitmqstream.connection. 前缀来传递任何配置属性。

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

Kafka 接收器的行为现在可以通过自定义逻辑来修改，为特定功能提供替代实现。当替代实现不可用时，则使用默认实现。

有关更多详细信息，请参阅 Apache Kafka Injection points。

Amazon Simple Queue Service (Amazon SQS) 是一种分布式消息队列服务。它支持通过 Web 服务应用程序以编程方式发送消息，作为通过 Internet 进行通信的方式。SQS 旨在提供一个高度可扩展的托管消息队列，以解决常见的生产者-消费者问题或生产者和消费者之间的连接性问题。

Debezium 2.5 提供了将事件发送到 Amazon SQS 的可能性。

得益于 Lars Johansson 的贡献，Debezium 2.5 在其产品组合中引入了一个新连接器，用于从 IBM Informix 收集更改。IBM Informix 是一个可嵌入的高性能数据库，可将 SQL、NoSQL、JSON、时间序列和空间数据集成在一个地方。它专为边缘、云或本地分析而设计。

IBM Informix 连接器与我们任何社区主导的连接器一样打包，可在 Maven Central 上找到，或者您可以从我们的 Debezium 2.5 发布页面下载插件存档。

Maven 构件坐标为：

如果您想为 Informix 连接器做出贡献，我们在 Debezium 组织下添加了一个新仓库，debezium-connector-informix。

我要感谢 Lars Johansson 的贡献和与团队的合作，赞！

社区长期以来一直利用 MySQL 连接器作为捕获 MariaDB 更改的替代方案；然而，这种兼容性主要是尽力而为。

Debezium 2.5 版本流旨在通过一种清晰系统的方法，逐步检查、验证并最终以与 MySQL 相同的容量支持 MariaDB，从而将 MariaDB 推向前台，成为一流的连接器。我们的目标和希望是可以在 MySQL 连接器本身范围内完成此工作；然而，GTID 支持仍有相当多的持续调查，这可能会影响未来的发展方向。

Debezium 2.5 的第一个预览版本已迈出第一步，我们已验证代码可以在单个 MariaDB 数据库部署上运行，测试套件已通过，并且我们已对 Binlog 客户端进行了必要的更改以支持该部署。我们的下一步是研究 GTID 支持，MariaDB 支持 GTID，但使用一种与 MySQL 不兼容的方法。

请继续关注未来的版本，我们将继续扩展此功能，并且我们非常欢迎任何早期反馈。

MySQL 和 MariaDB 都支持全局事务标识符 (GTID)。这些在复制中用于唯一标识集群中的事务。MySQL 和 MariaDB 之间的实现细节差异很大，在 Debezium 的早期版本中，我们仅支持 MySQL 的 GTID。

在 Debezium 2.5 中，我们通过在 MySQL 连接器产品中引入对 MariaDB 的 GTID 支持，又向前迈进了一步。为了利用此功能，您需要使用 MariaDB 驱动程序而不是 MySQL 驱动程序，方法是使用以 jdbc:mariadb 而不是 jdbc:mysql 开头的 JDBC 连接。通过这样做，您现在可以像 MySQL 一样充分利用 MariaDB 和 GTID 进行工作。（DBZ-1482）。