Debezium 团队很高兴地宣布 Debezium 3.3.0.Final 现已可用。此版本包含大量新功能，包括新的 Debezium Quarkus 扩展，为 Debezium 与 Quarkus 中的 PostgreSQL 提供无缝集成，支持 Apache Kafka 4.1，为所有核心连接器提供精确一次语义支持，为 MongoDB 和 JDBC sink 连接器提供 OpenLineage 支持，以及更多内容！
在本文中，我们将深入探讨 Debezium 3.3 中的所有变更，讨论新功能，并解释所有可能对您的升级过程产生影响的更改。一如既往，我们建议您阅读 发布说明，以了解所有已修复的错误、更新程序等。
重大变更
任何新软件版本通常都会带来一些破坏性更改。本次发布也不例外，因此在升级到 Debezium 3.3.0.Final 之前，让我们来讨论一下您应该了解的主要更改。
Debezium Core
已移除弃用的快照模式
在 Debezium 2.6 中，我们统一了快照模式的名称以符合其预期功能，其中包括
-
弃用了
schema_only_recovery，并替换为recovery。 -
弃用了
schema_only，并替换为no_data。
从 Debezium 3.3 开始，schema_only_recovery 和 schema_only 都已被移除（DBZ-8171）。仍然依赖这些已弃用模式的连接器配置在升级后会导致无效配置错误，因此调整连接器配置至关重要。
Debezium Engine 类加载器更改
Debezium Engine 未设置线程上下文类加载器，这可能会使与 Spring Boot 等项目的集成变得复杂。现在已设置线程上下文类加载器，Debezium Engine 使用提供的类加载器加载所有类，而不仅仅是连接器（DBZ-9375）。
Debezium JDBC Sink
JDBC Sink 数据类型精度更改
升级到 Hibernate 7.1.0.Final 带来了更精确的数据类型处理，特别是对于时间和浮点数据（DBZ-9481）
- 时间类型
-
time和timestamp列现在默认具有更高的精度。例如，Oracle 的 time 和 timestamp 列将使用 9 位精度创建，而不是之前的默认 6 位精度。 - 浮点类型
-
Debezium 明确倾向于使用
float、real和double precision来表示浮点值。如果您需要 Oracle 的二进制浮点和双精度数据类型，请在连接器配置中将hibernate.dialect.oracle.use_binary_floats设置为true。
| 只有新的时间类型列将使用新的 9 位精度添加，而现有列不受影响。如果您希望现有列以更高的精度定义以保持一致性，则必须手动完成。 |
Debezium for Db2
Offset 位置验证不可靠
由于 Db2 中偏移量位置验证的可靠性问题，我们已暂时禁用验证以防止错误失败（DBZ-9470）。因此，目前无法为 Db2 连接器使用 when_needed 快照模式。
影响：如果您正在使用 when_needed 快照模式与 Db2，您将需要使用替代模式，直到此限制在未来的版本中得到解决。
Debezium for Cassandra
Cassandra JMX 指标已更改
在 Debezium for Cassandra 连接器的早期版本中，每个 JMX 指标都作为不同的 MBean 出现在 <logical-name> 域中，如下例所示
#domain = <logical-name>:
<logical-name>:name=commitlog-filename
<logical-name>:name=commitlog-position这种方法与其他连接器的方法有显著不同，其他连接器的方法有一个具有多个 MBean 的单一域，例如：
#domain = debezium.cassandra:
debezium.cassandra:context=snapshot,server=<logical-name>,type=connector-metrics
debezium.cassandra:context=streaming,server=<logical-name>,type=connector-metrics现在，任何与快照相关的指标都将在 snapshot MBean 中，而与流相关的指标将在 streaming MBean 中（DBZ-9281）。以 commitlog-filename 为例，它现在在 streaming MBean 中称为 CommitLogFilename。
| 有关新 JMX 指标名称的所有详细信息，请参阅 Cassandra 文档。 |
新功能和改进
以下描述了 Debezium 3.3.0.Final 中所有值得注意的新功能和改进。如需完整列表，请务必阅读 发布说明 以获取更多详细信息。
Debezium Core
Kafka 4.1.0 为更好的性能奠定基础
Debezium 3.3.0.CR1 是基于 Kafka Connect 4.1.0 构建的，并已与 Kafka Broker 版本 4.1.0 进行了彻底的测试（DBZ-9460）。这确保了 Debezium 可以在最新、最稳定的 Kafka 基础设施上运行。
| 在升级之前，请参阅 Kafka 文档，以确保与您现有的 Kafka Broker 版本兼容。 |
Exactly-Once 语义支持
社区中有大量关于 Debezium 支持 Exactly-Once 语义的请求。通俗地说，Exactly-Once 语义意味着一个事件应该只被传递和写入 Kafka 主题一次，从而避免了重复的可能性。
我们很高兴地宣布，Debezium 3.3 为所有核心连接器引入了 Exactly-Once 语义支持，包括 MariaDB、MongoDB、MySQL、Oracle、PostgreSQL 和 SQL Server（DBZ-9177）。
禁用上下文头
在 Debezium 3.2 中，我们引入了几个新的头，为 OpenLineage 提供上下文，这些头会自动添加到每个发出的事件中。一些用户报告了这些头被添加但无法禁用，因为某些环境需要保持事件负载尽可能精简。
基于社区反馈，我们引入了一个新的配置选项 extended.headers.enabled，可以将其设置为 false，从而禁用这些上下文事件头的添加（DBZ-9248）。
心跳不再持续发出
在 Debezium 3.3.0.Alpha1 中，用户在使用 heartbeat.action.query 时报告了问题，即 Debezium 会持续发出心跳事件，而不管配置的间隔。此回归已修复，heartbeat.action.query 现在应该可以再次遵守配置的 heartbeat.interval.ms（DBZ-9340）。
连接器启动因模糊错误而失败
我们已解决一个导致连接器启动失败并出现误导性错误消息的问题，恢复了平稳启动，同时保留了改进的偏移量验证。
用户在连接器启动期间在一个角落案例中开始遇到此令人困惑的异常
org.apache.kafka.connect.errors.DataException: Invalid value: null used for required field: "schema", schema type: STRING此模糊的错误消息没有提供关于实际问题的任何有用信息，使得故障排除几乎不可能。
该问题是我们最近对偏移量验证所做改进的一个意外后果。我们增强了逻辑，以便在源数据库中不再提供偏移量位置时提供更好的错误消息——这是一个有价值的功能，有助于诊断常见的操作问题。
然而，新的验证逻辑假设在连接器启动期间某些偏移量属性可用。实际上，这些属性要到连接器生命周期的后期才会被填充，导致验证过早失败并显示无用的错误消息。
我们已更新异常处理逻辑以：
-
避免在启动时假设偏移量属性可用性
-
保留对偏移量确实无效情况的增强验证
-
在偏移量位置确实存在问题时提供有意义的错误消息
-
允许正常启动进行，而没有误报
此修复确保您在没有启动中断的情况下获得增强的错误报告的好处（DBZ-9416）。
失败的即席阻塞快照后可能发生数据丢失
我们已解决一个关键问题，该问题可能导致即席阻塞快照出现问题时发生数据丢失，确保即使快照失败，您的流数据也能保持完整。
在运行即席阻塞快照时，表中出现无效数据会导致快照失败。不幸的是，此失败有一个严重副作用：快照期间发生的流事件将永久丢失。
这意味着，如果您的快照运行了几个小时才遇到错误数据，那么在连接器恢复正常流操作时，这几个小时内的所有实时更改都将被完全跳过。
阻塞快照现在可以通过以下方式优雅地处理故障：
-
保留快照开始前立即的流位置
-
在快照失败时自动从正确的位置恢复
-
确保无论快照何时或为何遇到问题，都不会丢失任何数据
此改进使得阻塞快照在生产环境中更加可靠（DBZ-9337）。
Debezium for MongoDB
从特定位置开始
Debezium 用户现在可以通过在连接器配置中指定新的连接器配置属性 capture.start.op.time，在 MongoDB oplog 的特定位置启动 MongoDB 源连接器。此新配置属性应为 long 数据类型值，表示 BSON 时间戳（DBZ-9240）。
| 将此配置属性保留在连接器配置中，将导致连接器在重启时尝试从指定位置恢复。 建议在使用此功能时，一旦连接器开始流式传输更改，就删除该属性，以便将来的重启能够遵循连接器偏移量中的恢复位置。 |
MongoEventRouter 支持自定义追踪值
MongoEventRouter 现在支持将自定义追踪配置值传递给路由器，以便在事件负载中可用（DBZ-9328）。可以提供以下配置选项：
| 属性 | 描述 |
|---|---|
| 包含序列化跨度上下文的 |
| 表示 Debezium 处理跨度的操作名称，默认为 |
| 设置为 |
Debezium for MariaDB
MariaDB 11.7+ 向量数据类型支持
MariaDB 11.7 引入了 VECTOR(n) 数据类型，允许将关系数据库中的值存储为向量数据库。由 AI 模型生成的向量值可以使用此新数据类型在 MariaDB 中存储和搜索。
Debezium 3.3 在 MariaDB 源连接器和将数据写入 MariaDB 目标数据库的 JDBC Sink 连接器中引入了 MariaDB 向量数据类型支持（DBZ-8582）。
Schema 历史记录改进
MariaDB Schema 历史记录主题由连接器用于存储从二进制日志捕获的各种 DDL 操作，允许连接器从 Schema 更改的历史记录中构建关系模型。
在 Debezium 3.3 中，Schema 历史记录主题的过滤器已更新，以避免将与 Debezium 功能无关的特定语句存储在主题中，例如存储过程、函数、视图、触发器和 GRANT/REVOKE 语句（DBZ-9186）。
| 对于新连接器，此类语句将不会被存储。对于现有连接器，只有符合改进过滤器的已捕获 DDL 语句才会被省略，现有的主题事件不会被移除。 |
Debezium for MySQL
Schema 历史记录改进
MySQL Schema 历史记录主题由连接器用于存储从二进制日志捕获的各种 DDL 操作，允许连接器从 Schema 更改的历史记录中构建关系模型。
在 Debezium 3.3 中，Schema 历史记录主题的过滤器已更新，以避免将与 Debezium 功能无关的特定语句存储在主题中，例如存储过程、函数、视图、触发器和 GRANT/REVOKE 语句（DBZ-9186）。
| 对于新连接器，此类语句将不会被存储。对于现有连接器，只有符合改进过滤器的已捕获 DDL 语句才会被省略，现有的主题事件不会被移除。 |
Debezium for PostgreSQL
文本搜索向量支持
在 PostgreSQL 13+ 中，添加了全文搜索数据类型。tsvector 数据类型以一种优化文本搜索的形式表示文档，提供一个排序的唯一词典列表。
使用 Debezium 3.3，您现在可以捕获使用 tsvector 数据类型进行的列更改（DBZ-8470）。这些列类型使用称为 io.debezium.data.Tsvector 的逻辑类型发出，并在事件中表示为字符串数据类型。
JDBC Sink 中的 TSVECTOR 数据类型支持
发布 DDL 超时
虽然我们通常不记录内部配置属性，但过去我们添加了一个新的内部 PostgreSQL 连接器配置属性 internal.create.slot.command.timeout，在创建连接器复制槽时应用 90 秒的默认超时。这是为了解决阻塞事务的问题，这些事务会阻止连接器前进，因为在有活动事务时无法创建复制槽。
在 Debezium 3.3 中，我们将超时的覆盖范围扩展到创建和修改 PostgreSQL 连接器发布的 DDL 操作（https://issues.redhat.com/browse/DBZ-9310）。如果您在创建/更新发布或复制槽时遇到超时，您可能希望增加此配置属性（默认为 90）或将其设置为 0 来禁用超时功能。
改进 TOAST 列性能
Debezium for PostgreSQL 的 pgoutput 解码器使用一种特定模式来确定 TOAST 列的值是否与预定义的标记对象列表匹配，这些对象表示值在更改事件中不存在。然而，当事件负载包含大型文本或二进制数据时，由于在比较之前计算哈希值的开销，这种模式的效率不高。
为了提高性能，该实现现在使用直接相等性检查，避免了对大型 TOAST 列负载进行昂贵的哈希计算（DBZ-9345）。此更改减少了处理具有大文本或二进制数据的事件时的处理开销。
仅在需要时修改发布
当 Debezium PostgreSQL 连接器配置为 publication.autocreate.mode 为 filtered 时，连接器会在每次连接器重启时发出 ALTER PUBLICATION 语句，以确保发布与连接器配置保持一致。
在某些情况下，当底层表正在进行 vacuum 或涉及长时间运行的 DDL 操作时，这将迫使连接器等待这些任务完成，然后才能完成 alter。为了简化这一过程，并且只在绝对必要时才阻塞，连接器现在会在使用filtered模式时，将配置的表列表与发布进行比较。只有当表列表存在差异时，才会执行 alter 命令，否则跳过以避免潜在的阻塞调用（DBZ-9395）。
Debezium for Oracle
旧的 decimal.handling.mode 行为
在 Debezium 2.7 中，我们引入了一个 bug 修复，将 Oracle 连接器中 decimal.handling.mode 使用 double 或 string 模式时的行为与 C 连接器进行了对齐。此 bug 修复更改了事件的 schema，并给那些因预期外更改而升级的用户带来了许多问题。
我们研究了各种选项，无论是通过 CustomConverter 还是 Transformation 来引入旧版支持，但我们得出结论，为了提供足够的解决方案，旧版支持需要内置到连接器中。
在 Debezium 3.3 中，添加了一个新的配置属性 legacy.decimal.handling.strategy，允许用户恢复使用已损坏的行为，其中零标度的数值不会自动转换为 double 或 string，而是作为整数值发出，只要其长度小于或等于 18（DBZ-9166）。
| 如果您是从 Debezium 2.7 之前的版本升级，建议您至少暂时启用此功能，以尽量减少升级到 Debezium 3.3 或更高版本的复杂性。 如果您已经升级到 Debezium 2.7 到 3.2，不建议启用此旧版行为，因为它会引入相同的 schema 更改复杂性，但反向。 |
LogMiner 实验性 CTE 查询支持
我们为 Oracle LogMiner 引入了一项新的内部实验性功能，它利用了 CTE 查询（Common Table Expression query）的概念。CTE 查询是一种 SQL 构造，它允许在执行另一个 SQL 操作的过程中定义一个临时、命名的结果集，这可能出于各种原因而有用。
对于 Debezium Oracle 连接器，新的 internal.log.mining.use.cte.query 功能会触发一个特殊的预扫描，该扫描会检查所有事务并执行预过滤。此过滤扫描旨在只为实际包含已捕获表的 DML 操作的事务发送 START、COMMIT 和 ROLLBACK 事件。换句话说，如果有人执行了 100 个事务，而其中只有一个事务修改了您已捕获的表，那么我们不仅不会收到其他 99 个事务的 DML 事件，而且事务标记也会被省略（DBZ-9272）。
| 此功能并非没有缺点，最值得注意的是它需要两次遍历事务日志。对于非捕获表与捕获表之间变更量不成比例较高的系统，额外的读取通道可能值得，以尽量减少通过网络和连接器处理无关事务标记事件的开销。 |
最后一次批处理吞吐量指标得到改进
我们改进了 Oracle LogMiner 适配器中 LastBatchProcessingThroughput JMX 指标的准确性，让您能够更好地了解连接器的性能。
以前，此指标根据每个批处理中实际处理的捕获表事件的数量来计算吞吐量。虽然这似乎合乎逻辑，但在几种常见情况下会导致误导性的结果：
-
数据库级别的过滤会减少已处理事件的数量，即使连接器仍在执行读取和评估这些过滤记录的工作
-
事件流中的事务标记可能会扭曲数字，有时会严重低估实际处理负载
-
各种配置设置会以不反映连接器真实性能的方式影响指标
该指标现在根据从 LogMiner 数据集中读取的 JDBC 行数来衡量吞吐量，无论这些行是否最终被
-
在 JVM 中被您的配置过滤掉
-
事务控制记录
-
不匹配您的表或模式过滤器的事件
这让您对 Debezium 连接器在每个批处理处理窗口期间提供的原始处理能力有了更准确的了解（DBZ-9399）。
更智能的归档目标管理
对于某些 Oracle 连接器环境，可以使用新的基于优先级的归档目标策略。以前，用户必须指定一个单一目标（例如 LOG_ARCHIVE_DEST_2），这在主节点使用不同目标名称的故障转移场景中需要手动更改配置。
用户现在可以使用逗号分隔的列表以优先级顺序配置多个目标（DBZ-9041）。例如，LOG_ARCHIVE_DEST_1,LOG_ARCHIVE_DEST_2。连接器将智能地选择第一个本地且有效的目标，适应不需要配置更改的故障转移场景。
例如，Oracle 主实例使用 LOG_ARCHIVE_DEST_1，备用实例使用 LOG_ARCHIVE_DEST_2。使用新的优先级顺序功能，当发生故障转移时，连接器会无缝地从 LOG_ARCHIVE_DEST_1 切换到 LOG_ARCHIVE_DEST_2。
| 请注意，这仅在灾难恢复故障转移场景中备用环境成为新主环境时才有用。这与 Oracle Real Application Cluster (RAC) 节点不可用且连接器连接到集群中下一个可用节点的情况不同。在后者中，集群中的所有节点共享相同的归档目标配置，优先级顺序不适用。 |
XStream 事件中提供 Commit SCN
所有 Debezium 更改事件默认都包含一个 source 信息块。对于 Oracle，此块包含一个 commit_scn 字段，该字段表示事务提交事件的系统更改编号 (SCN)。
以前，commit_scn 仅在使用 Oracle LogMiner 时填充。在此版本中，我们还扩展了对 Oracle XStream 的支持（DBZ-9497）。
XStream 不再刷新无效的低水位标记
Debezium Oracle XStream 实现必须定期将 LCR 位置刷新到 Oracle Outbound Server。此刷新就像 PostgreSQL 向复制槽确认 LSN 一样，提示 Oracle 该位置之前的所有更改都已处理完毕。
以前，由于偏移量刷新的处理方式，Oracle Outbound Server 在尝试刷新低水位标记时可能会错误地报告失败，将有效位置视为无效。此问题现已修复，Oracle Outbound Server 将不再虚假地报告无效的低水位标记位置（DBZ-8923）。
Debezium for SQL Server
心跳改进
SQL Server 中的心跳行为现在将在 CDC 表没有更改的期间发出心跳事件（DBZ-9364）。这应该有助于确保，即使数据库中的 LSN 由于非捕获表的更改而继续前进，偏移量也能保持同步。
Debezium JDBC Sink
自我修复数据库错误
JDBC Sink 连接器现在会自动重试在更改处理过程中发生的 SQL 异常，为自我修复场景提供关键的缓冲，以提高连接器的弹性（DBZ-7772）。
这在多任务环境中尤其有价值，在这些环境中，对同一表的并发写入可能会导致锁冲突。连接器不再完全失败或将重启委托给运行时，而是自行从这些瞬态问题中恢复，从而显著提高了连接器的整体可靠性。
Debezium for CockroachDB
CockroachDB 新的源连接器
一个新的 CockroachDB 连接器，处于实验阶段且正在积极开发中，由社区与 Cockroach Labs 共同领导（DBZ-9289）。此连接器建立在 CockroachDB 的 change-feed 子系统之上，用于捕获行级更改，并将这些更改作为更改事件发出。
此新连接器需要 CockroachDB 25.2+ 并启用 rangefeed 选项，以及 Java 21+。此连接器目前处于孵化阶段，由社区大力开发。
如果您想开始使用此连接器，您可以使用以下坐标获取该连接器：
<dependency>
<groupId>io.debezium</groupId>
<artifactId>debezium-connector-cockroachdb</artifactId>
<version>3.3.0.Final</version>
</dependency>此连接器的文档仍在开发中，但您可以在存储库的 README 中找到有关其配置选项和使用方法的信息。
Debezium for Informix
增强的默认值本地化支持
Informix 连接器现在能更智能地处理区域设置相关的数据库配置（DBZ-9181）。连接器不再假定为美国区域设置，而是根据您实际的数据库配置正确解析区域设置相关的 DBMONEY、DBCENTURY 和 DBDATE 等值。
此改进确保了跨不同国际部署更准确的数据捕获，并消除了非美国环境中的潜在数据解析错误。
Debezium 服务器
Azure Event Hubs - 内置哈希分区键
Azure Event Hubs 的分区键最多限制为 128 个字符。如果事件的键导致分区键超出该限制，Debezium Server 的 Azure Event Hubs Sink 适配器将抛出异常，连接器将终止。这种行为不太理想，并对无法在源头解决的源表造成了限制。
为解决此问题，可以将 Azure Event Hubs Sink 配置为使用几种哈希算法之一，以遵守最大分区键大小，同时处理分区键否则将超出最大允许大小的源数据（DBZ-9245）。
要使 Azure Event Hubs Sink 使用内置的分区键哈希，必须使用 debezium.sink.eventhubs.hashmessagekey 配置属性（默认为 false）设置为 true 来配置 Sink。启用后，可以将 debezium.sink.eventhubs.hashmessagekeyfunction 设置为 java（默认）、md5、sha1 或 sha256 来确定使用的哈希算法类型。
NATS Jetstream - 异步事件分发
Debezium Server NATS Jetstream Sink 适配器以前依赖于同步发布，这在高吞吐量流场景中存在性能限制。为了支持高吞吐量流场景，NATS Sink 支持两个新的配置选项（DBZ-9474）
| 属性 | Default (默认值) | 描述 |
|---|---|---|
|
| 指定 Sink 适配器是否应使用异步发布。 |
|
| 异步发布调用因超时而失败之前的毫秒数。 |
在此版本中，新的异步发布功能默认启用，但可以通过将 async.enabled 设置为 false 来禁用。
| 所有 Debezium Sink 适配器配置都有一个唯一的prefix。如果您需要自定义这些配置的默认值，请确保将这些新配置加上 |
Debezium 平台
新的智能编辑器
管理不同运行时中相似的 Debezium 连接器会带来独特的维护挑战，因为每个运行时使用不同的格式，例如 Kafka Connect 使用 JSON，而 Debezium Server 使用键/值属性文件。Debezium Platform 还使用自己的基于 JSON 的格式，该格式与 Kafka Connect 略有不同，这增加了另一个复杂层。
新的连接管理
您现在可以将连接凭据和详细信息与源和目标配置分开管理（DBZ-9314）。这简化了连接管理，因为您可能拥有多个连接到同一源或目标系统的管道。
在此屏幕截图中，您可以看到如何管理和添加新连接。
在此屏幕截图中，您可以看到如何查看和编辑连接详细信息。
在创建新的源或目标时，您可以选择是创建新连接还是重用现有连接以简化操作。
在更改时通知用户管道重启
在使用 Debezium Platform 时，源、目标或其他资源可能在两个或多个管道之间共享。在对这些资源进行更改时，任何使用该资源的管道都必须重启才能使更改生效。
为了避免因管道重启而导致意外结果，Debezium Platform 会在进行可能导致管道重启的更改时通知用户，以便应用更新的配置（DBZ-9104）。
Debezium Quarkus 扩展/集成
Debezium 产品组合中最新的添加之一是 Debezium Quarkus 扩展，它使开发人员能够在 JVM 或 Native 构建的 Quarkus 应用程序中直接利用 Debezium 的 CDC 功能。我们添加了一些新改进，让我们分别介绍。
心跳监听器
Debezium 可以通过 heartbeat.interval.ms 进行配置，以便 Debezium 定期向事件流发出心跳事件。心跳事件可用于多种原因，但其主要用途是确保偏移量在捕获表活动低/无期间仍与源数据库的当前读取状态保持一致。
使用 Debezium 扩展的 Quarkus 应用程序还可以通过观察 CDI 事件 DebeziumHeartbeat 在发出心跳时执行其他操作。这允许为每个心跳执行应用程序特定的代码（DBZ-8960）。
在下面的示例中，监听器仅在观察到心跳时写入控制台。
@ApplicationScoped
public class HeartbeatListener {
public void consoleHeartbeat(@Observes DebeziumHeartbeat event) {
System.out.println("Debezium emitted a heartbeat event!");
}
}轻松实现自定义转换器
Debezium CustomConverter 是一种工具，可用于更改 Debezium 发出给定列类型的值的方式。这对于需要特定格式数据的使用者来说可能非常强大。
在您的 Quarkus 应用程序中，您可以通过在 application.properties 文件中将其指定为连接器配置的一部分来定义 CustomConverter；但是，Debezium 3.3 添加了一种新的基于注解的方法，可以简化配置，并使迭代开发更快、更轻松（DBZ-8966）。
例如，以下内容展示了一个定义转换器的过程，该转换器接收给定的原始字段并使用 Java 的 toString() 函数将其值作为*字符串*在事件中返回。
@ApplicationScoped
class RawToStringConverter {
@CustomConverter
public ConverterDefinition<SchemaBuilder> bind(ConvertedField field) {
return new ConverterDefinition<>(SchemaBuilder.string(), Object::toString);
}
}此外，自定义转换器可以有选择地应用于字段。开发人员可能倾向于在自定义转换器注解方法中实现此行为，虽然这有效，但可以使用组件驱动的方式使用 FieldFilteringStrategy 来实现。
例如，以下内容展示了相同的自定义转换器，但使用了字段过滤策略
@ApplicationScoped
class RawToStringConverter {
@CustomConverter(filter = CustomFieldFilteringStrategy.class)
public ConverterDefinition<SchemaBuilder> bind(ConvertedField field) {
return new ConverterDefinition<>(SchemaBuilder.string(), Object::toString);
}
}
@ApplicationScoped
class CustomFieldFilteringStrategy implements FieldFilteringStrategy {
@Override
public boolean filter(ConvertedField field) {
/* implement your selective logic here */
return false;
}
}CDC 事件作为 POJO
Debezium Quarkus 扩展将更改事件作为结构化的 ChangeEvent<K, V> 类型发出。但在某些情况下，将更改事件转换为 Java record 或特定领域的 POJO 可能很有用。对于这些情况，Debezium 的 Quarkus 扩展提供了一种将 ChangeEvent 反序列化为 Java record 或 POJO 的标准化方法。
例如，假设我们的源中有一个 products 表，我们有一个捕获处理程序。在此处理程序中，我们希望处理 Product 对象，如下所示。
@ApplicationScoped
class ProductHandler {
@Capturing(destination = "prefix.inventory.products")
public void captureProducts(Product product) {
/* do something with product */
}
}为了实现这一点，需要实现一个 Deserializer<T> 来将 ChangeEvent 转换为目标 POJO 类型 Product。该扩展提供了一个使用 Jackson 的实现来处理此问题的 ObjectMapperDeserializer。
public class ProductDeserializer extends ObjectMapperDeserializer<Product> {
public ProductDeserializer() {
super(Product.class);
}
}最后一步是定义 Quarkus 配置中的反序列化映射，以将其连接在一起。
quarkus.debezium.capturing.product.destination=prefix.inventory.products
quarkus.debezium.capturing.product.deserializer=<the-java-package>.ProductDeserializer该扩展将使用此配置将目标为 prefix.inventory.products 主题的事件映射到使用 product 反序列化器。此反序列化器映射到 <the-java-package>.ProductDeserializer 类，该类使用 Jackson 将 ChangeEvent 转换为 Product 对象。转换后，使用 Product 对象而不是发出的 ChangeEvent 调用带有 @Capturing 注解的方法。
Debezium Quarkus Outbox 扩展
支持最新的 Quarkus
Debezium Quarkus Outbox 扩展像大多数 Quarkus 基础的扩展一样依赖 Hibernate 进行持久化，在最新的 Quarkus 3.23.x 中，Hibernate 版本更新到了 7.x。新版本的 Hibernate 引入了各种破坏性更改，导致扩展不兼容。
使用 Debezium 3.3（以及即将发布的 Debezium 3.2.1 的反向移植），Debezium Quarkus Outbox 扩展与最新版本的 Quarkus 兼容，并且可以与 Hibernate 7+ 一起工作（DBZ-9219）。
| 由于兼容性更改，在使用 Debezium 3.2.0.Final 或更早版本时，Quarkus 应用程序必须基于 Quarkus 3.22.x 或更早版本。只有在使用 Debezium 3.2.1 / 3.3.x 或更高版本时才能使用 Quarkus 3.24.x 或更高版本。 |
OpenLineage 集成
支持 Debezium Sink 连接器
OpenLineage 能够捕获数据管道中的丰富元数据。在此版本中，我们将 OpenLineage 集成扩展到 JDBC 和 MongoDB Sink 连接器（DBZ-9469）。
其他修复
以下是 Debezium 3.3 中一些值得注意的额外更改和修复的子集
-
在 Oracle 只读副本中执行 Debezium DBZ-8319
-
跨两个查询提取的事务可能随机导致不支持的操作 DBZ-8747
-
Debezium Engine Quarkus 扩展：引入 PostProcessor 处理程序 DBZ-8965
-
在挖掘会话期间，将 ORA-00310 重做日志视为不一致 DBZ-8870
-
JdbcSchemaHistory 在恢复记录时未能处理数据分片 DBZ-8979
-
为缓存事件添加 JMX 指标/统计信息 DBZ-8991
-
ORACLE NVARCHAR 数据中的 '||' 会导致异常 DBZ-9132
-
在使用非恢复快照模式时，偏移量未重置 DBZ-9208
-
增量快照偏移量在任务重启时无法加载 DBZ-9209
-
SqlServer 的日志位置验证可能会失败 DBZ-9212
-
可能出现回归，抛出 DebeziumException 而非警告 DBZ-9217
-
通过 NATS Jetstream sink 双重发布事件 DBZ-9221
-
由于 DebeziumHeaderProducer 未注册，抛出 NullPointerException DBZ-9225
-
MongoDB ExtractNewDocumentState SMT 在 3.2 版本中崩溃，出现数组中的嵌套结构 DBZ-9231
-
Mongodb 增量快照未遵守附加条件 DBZ-9232
-
Oracle 快照边界模式没有字段显示名称 DBZ-9236
-
请求修复 jdbc postgres 目标的多任务 CREATE TABLE 冲突，导致任务崩溃 DBZ-9237
-
异常大的挖掘窗口可能导致意外的指标/性能问题 DBZ-9241
-
在 Debezium-connector-postgres 上，当心跳表缺失时抛出异常 DBZ-9247
-
允许 Oracle 心跳操作查询错误处理程序对 ORA-02396 保持弹性 DBZ-9280
-
OpenLineage 输出数据集使用错误的数据类型 DBZ-9285
-
Debezium platform 验证信号数据收集失败 DBZ-9290
-
AsyncEmbeddedEngine 中的 OffsetStorageWriter.doFlush() 抛出未检查的异常，导致 OffsetStorageWriter 中的信号量未释放，可能导致引擎失败 DBZ-9292
-
Reselect 后处理器无法处理 VariableScaleDecimal 主键 DBZ-9293
-
Debezium Server Azure Event Hubs sink 重复所有之前的事件 DBZ-9304
-
使用基于 pgoutput 插件的 postgres 连接器时出现重复键异常 DBZ-9305
-
归档日志仅模式在没有更多可用数据时不会暂停挖掘 DBZ-9306
-
源和目标实体必须链接到连接实体 DBZ-9333
-
使用多个任务时，事件可能会被错误地处理多次 DBZ-9338
-
允许重做线程刷新 SCN 调整可配置 DBZ-9344
-
获取事务事件计数可能导致 NullPointerException DBZ-9349
-
确保 dbz 服务器启动时 JAVA_OPTS 环境变量正确 DBZ-9352
-
当字段的 schema 类型为 BYTES 时，ReselectColumnsPostProcessor 出现问题 DBZ-9356
-
当表结构更改并抛出 ORA-01466 时，Oracle 无法重新选择列 DBZ-9359
-
在创建操作中，单引号被双引号括起来 DBZ-9366
-
使用归档日志仅模式时，挖掘上限计算错误 DBZ-9370
-
Oracle 连接器不支持大型 CLOB 和 BLOB 值 DBZ-9392
-
增加允许的最大 JSON 字符串长度 DBZ-9407
-
task.management.timeout.ms 的错误默认值 DBZ-9408
-
LCR 刷新可能导致低水位线失效 DBZ-9413
-
增量快照期间上下文头被添加两次 DBZ-9422
-
向 Debezium Platform 添加缺失的目标 DBZ-9442
-
Oracle 连接器重新选择异常处理（ORA-01555 + ORA-22924）DBZ-9446
-
Debezium Server 因 CNFE 失败 DBZ-9468
-
在重新创建快照可调用表的列表时发生 OutOfMemory 异常 DBZ-9472
-
Debezium Server 对 SqlServer 源报告“AttributeNotFoundException QueueTotalCapacity”DBZ-9477
-
当列名包含反引号时，出现“未知列在 'field list' 中”DBZ-9479
-
MySQL 事件获取头信息时抛出 NullPointerException DBZ-9483
-
如果 additional-conditions 不正确，Adhoc 阻塞快照可能导致流永远暂停 DBZ-9494
-
快照期间，当表没有列时，出现“table is null” DBZ-9500
-
Postgres 连接器修复 LSN flush 操作中的过度线程创建。DBZ-9501
-
删除主键不会更改 Oracle 关系元数据 DBZ-9505
非常感谢社区中所有辛勤工作的贡献者为这个版本付出的努力
Ahmed Bayraktar、Aleksei Silantev、Alvar Viana Gomez、Anil Dasari、Animesh Kumar、Anisha Mohanty、Artem Shubovych、Barbara Lócsi、Bhagyashree Goyal、Chirag Kava、Chris Cranford、Gabriel Cerioni、Giovanni Panice、Guangnan Shi、Harris Nguyen、Hesjona Hilaj、Indra Shukla、Jakub Cechacek、Jiri Pechanec、Joan Gomez、John Tanza、Jona J、Jonathan Schnabel、Lars M. Johansson、Liam Wu、Lucas Gazire、Luke Alexander、Marci、Mario Fiore Vitale、Matt Bayley、Nick Chomey、Olivier Chédru、Pierre-Yves Péton、Pranav Tiwari、Rajendra Dangwal、René Kerner、Robert Roldan、Seokjae Lee、Sergei Nikolaev、Shubham Kalla、Shyama Praveena S、Stefano Linguerri、Thomas Thornton、Vipin Kalra、Vojtěch Juránek、Wouter Coekaerts，以及 leoloel！
关于 Debezium
Debezium 是一个开源的分布式平台，可以将现有数据库转变为事件流，使应用程序能够几乎即时地看到并响应数据库中已提交的每个行级更改。Debezium 构建在 Kafka 之上，并提供了 Kafka Connect 兼容的连接器，用于监控特定的数据库管理系统。Debezium 将数据更改的历史记录在 Kafka 日志中，这样您的应用程序可以随时停止和重新启动，并可以轻松地消费在未运行时错过的所有事件，确保所有事件都被正确且完整地处理。Debezium 在 Apache 许可证 2.0 下是 开源 的。
