Debezium 2.5.0.Beta1 现已推出。此版本包括许多改进，例如对 MariaDB GTID 的支持、Debezium Server EventHub 接收器的分区、本机 RabbitMQ 流 Debezium Server 接收器、来自 PostgreSQL 16 备用数据库的流式传输、MySQL 高精度源时间戳、使用 JDBC 接收器的字段包含/排除、初始快照的一些附加通知以及 Debezium Operator CRD 的服务帐户支持。此外，此版本还包括各种错误修复和一些重大更改。

一、重大变化

此版本包含多项重大更改。

1.分片部署中的 MongoDB 快照

在 Debezium 的早期版本中，用户可以使用 MongoDB 连接器，并在使用 MongoDB 分片部署时在特定分片上执行集合快照。不幸的是，虽然我们知道用户可能利用了此行为，但这是无意的且不受支持。

Debezium 2.5 完全删除了这种功能，完全弃用并删除 MongoDB 中的副本集流模式是未来目标中的一步。

2.移除ComputePartition SMT

ComputePartition 是一个 SMT，使用户能够计算所需的分区，并为其在 Kafka 主题中写入事件。此单消息转换 (SMT) 不久前已被弃用，取而代之的是新的 PartitionRouting 单消息转换。

Debezium 2.5 删除了旧的、已弃用的 ComputePartition，并且可能仍在依赖此 SMT 的用户将需要迁移到新的 PartitionRouting SMT。

3.JDBC 接收器值序列化更改

报告了一个极端情况，即 JDBC 接收器连接器错误地将具有空值的字段写入目标数据库，并使用默认值而不是 NULL 值。

二、新功能和改进

Debezium 2.5 还引入了更多改进和功能，让我们分别看一下。

1.初始快照的附加通知

Debezium 的通知子系统提供了一种将外部流程和应用程序与某些 Debezium 任务（例如拍摄快照）集成的简单方法。在之前的版本中，初始快照的通知非常基本，并提供了详细信息，例如快照何时开始、每个表何时开始和结束以及最终快照何时结束。

提供有关快照的增强详细信息。例如，IN_PROGRESS 通知将提供有关正在捕获哪些表以及当前正在处理哪些表的更多详细信息，如下所示：

{"id":"6d82a3ec-ba86-4b36-9168-7423b0dd5c1d","aggregate_type":"Initial Snapshot","type":"IN_PROGRESS","additional_data":{"connector_name":"my-connector","data_collections":"table1, table2","current_collection_in_progress":"table1"},"timestamp": "1695817046353"
}

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

{"id":"6d82a3ec-ba86-4b36-9168-7423b0dd5c1d","aggregate_type":"Initial Snapshot","type":"TABLE_SCAN_COMPLETED","additional_data":{"connector_name":"my-connector","data_collection":"table1, table2","scanned_collection":"table1","total_rows_scanned":"100","status":"SUCCEEDED"},"timestamp": "1695817046353"
}

上面显示的几个字段（例如 data_collection）目前不适用于 MongoDB 快照，仅适用于基于 SQL 的关系连接器。

2.MySQL高精度源时间戳

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

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

3.MariaDB GTID 支持

MySQL 和 MariaDB 都支持所谓的全局事务标识符或 GTID。它们在复制中用于唯一地标识整个集群中的事务。 MySQL 和 MariaDB 之间的实现细节存在显着差异，在 Debezium 的早期版本中，我们仅支持 MySQL 的 GTID。

在 Debezium 2.5 中，我们又向前迈出了一步，引入了对 MariaDB 的 GTID 支持，作为 MySQL 连接器产品的一部分。为了利用此行为，您需要通过使用前缀为 jdbc:mariadb 而不是 jdbc:mysql 的 JDBC 连接来使用 MariaDB 驱动程序而不是 MySQL 驱动程序。通过这样做，现在可以像 MySQL一样充分利用 MariaDB 和 GTID。

计划在 Debezium 2.6 中为 MariaDB 引入一个新的独立连接器。我们在 2.5 中所做的很多工作都将延续到 2.6 中的这个新连接器，因此我们早期获得的任何反馈只会有利于 2024 年初的过渡！

4.从 PostgreSQL 16 备用服务器进行流式传输

在 PostgreSQL 16 中，现在可以在备用实例上定义复制槽。这带来了大量的新选项，包括从副本而不是生产系统执行更改数据捕获以进行负载分配的能力，特别是在非常活跃的数据库中。

Debezium 2.5 现在支持连接到备用 PostgreSQL 16 服务器和流式更改。

5.JDBC 接收器字段包含/排除

Debezium 2.5 引入了新的 JBDC 接收器功能，用户现在可以指定事件负载中的哪些字段要包含在目标数据库写入操作中或从目标数据库写入操作中排除。此功能的工作原理与 Debezium 框架中的任何其他包含/排除组合一样，其中这两个属性是互斥的。

例如，如果我们有一个简单的事件负载，主题客户中包含以下字段：

{"id": 12345,"name": "Acme","address": "123 Main Street"
}

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

阻止将地址字段写入目标的示例

{"field.exclude.list": "customers:address"
}

包含/排除字段的格式为 [<主题名称>:]<字段名称>，其中主题名称是可选的，如果您想避免写入所有事件的地址字段，则可以省略。

6.Debezium 服务器 - EventHubs 分区

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

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

如果需要额外的分区路由要求，您现在可以结合 PartitionRouting SMT 完成此类任务。

7.Debezium 服务器 - RabbitMQ Streams 接收器

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

debezium.sink.type=rabbitmqstream
debezium.sink.rabbitmqstream.connection.host=<hostname of RabbitMQ>
debezium.sink.rabbitmqstream.connection.port=<port of RabbitMQ>

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

8.Debezium Operator - CRD 服务帐户

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

Debezium 2.5 简化了此过程，允许现在使用自己的自定义服务帐户。