我怀着无比的喜悦和荣幸宣布 Debezium 3.0.0.Final 的可用性！
我们发布 Debezium 2.0 已近 2 年，在此期间，该平台不断发展，引入了 sink 连接器、新的社区主导连接器，以及对核心平台和连接器的广泛功能和改进。在社区的帮助下，Debezium 仍然是 CDC 的事实领导者。
3.0 版本标志着 Debezium 的又一个里程碑，这是我们迫不及待想分享的。
在这篇文章中，我们将深入探讨 Debezium 3.0 中的所有变化，讨论新功能，并解释所有可能影响您升级过程的潜在变更。一如既往，我们建议您阅读发布说明，了解所有已修复的错误、更新程序等。
Debezium 核心变更
在本节中，我们将深入探讨影响 Debezium 核心的变更，并讨论这些变更如何影响所有用户。
需要 Java 17
此版本更改了构建和运行 Debezium 所需的 Java 要求。此外，此版本需要更高版本的 Maven 才能从源代码构建 Debezium。
所有 Debezium 连接器都需要 **Java 17** 作为运行时基线。
如果您使用 Debezium Server、Operator 或 Quarkus Outbox Extension，则需要 **Java 21** 作为运行时基线。
如果您打算从源代码构建 Debezium，所有 Debezium 项目都需要 Java 21 和 Maven 3.9.8 或更高版本。当使用低于 Java 21 的 Java 版本从源代码构建 Debezium 时，构建将失败，并报告需要 Java 21 或更高版本。
请参阅以下图表，一览各组件的 Maven 和 Java 要求
| 组件 | Java (运行时) | Java (构建) | Maven (构建) |
|---|---|---|---|
Debezium 服务器 | Java 21+ | Java 21+ | 3.9.8+ |
Debezium 操作员 | Java 21+ | Java 21+ | 3.9.8+ |
Debezium Quarkus Outbox 扩展 | Java 21+ | Java 21+ | 3.9.8+ |
Debezium 连接器 | Java 17+ | Java 21+ | 3.9.8+ |
基于 Kafka 3.8 构建
此版本将 Kafka 3.8 作为我们测试和构建 Debezium 的基线。Kafka 3.8 更改了许多内部 API，这些 API 需要为 Debezium 的使用进行调整 (DBZ-8105)。
对于大多数用户，此更改没有影响；但是，如果您正在扩展 Debezium，了解这些更改非常重要。
移除已弃用的增量信号字段
在 Debezium 2.4 中，增量快照信号载荷中的 `additional-condition` 字段已弃用，被新的 `additional-conditions` 属性取代，该属性允许按表指定条件。在此版本中，旧的 `additional-condition` 字段已被移除，不再受支持 (DBZ-8278)。请务必更新您可能已引用的该旧的、已弃用字段的脚本、工作流或文档。
每个表的详细指标
Debezium 现在将开始跟踪每个关系表执行的创建、更新和删除操作的指标。对于 PostgreSQL 和 Oracle 等一些连接器，这些新的详细指标还跟踪每个关系表执行的截断操作。这对于需要检测特定变异模式或希望集成详细信息可用于识别问题的分析或可观察性堆栈的情况非常有用。
对于升级到 Debezium 3 的用户，新指标会自动捕获。它们使用 `Map
MariaDB 连接器变更
支持版本 11.4.3
Debezium 3 将 MariaDB 的基线支持迁移到最新的非滚动版本 11.4.3 (DBZ-8226)。我们还在密切关注 MariaDB 11.6 的发布周期，并计划在 MariaDB 11.6 稳定后引入向量数据类型支持。
MongoDB 连接器变更
MongoDB sink 连接器
Debezium 在 Debezium 2.2 中引入了第一个 sink 类型连接器，距今一年多，我们很高兴地宣布将 MongoDB 的另一个 sink 类型连接器作为 Debezium 3 的一部分。
与需要额外插件安装才能使用的 JDBC sink 关系型连接器不同，MongoDB sink 连接器与 MongoDB source 连接器捆绑在同一个工件中。因此，如果您已经安装或使用 MongoDB source 连接器并正在使用 Debezium 3 或更高版本，那么您也拥有 MongoDB sink 连接器。
开始使用 MongoDB 的配置非常简单，这是一个示例
{
"connector.class": "io.debezium.connector.mongodb.MongoDbSinkConnector",
"connection.string": "...",
"topics": "topic1,topic2",
"sink.database": "targetdb"
}`connection.string` 和 `sink.database` 配置属性是必需的。它们定义了连接到目标 MongoDB 数据库的详细信息以及要将更改写入的目标数据库的名称。
此外，`topics` 配置属性是 Kafka Connect 所必需的，它描述了一个逗号分隔的正则表达式列表，用于连接器将要观察的主题。
| 此连接器的文档仍在完善中，因此如果您有任何疑问或问题，请随时通过我们的社区渠道联系。 |
MySQL 连接器变更
MySQL 9
Oracle 连接器变更
已移除弃用的配置属性
已移除几个弃用的配置属性
-
`log.mining.transaction.retention.hours` 已替换为 `log.mining.transaction.retention.ms`
-
`log.mining.archive.destination.name` 已替换为 `archive.destination.name`
-
`log.mining.archive.log.hours` 已替换为 `archive.log.hours`
在使用已弃用的配置选项以保留旧行为时，请务必更新您的 Oracle 连接器配置 (DBZ-8181)。
默认日志挖掘策略已更改
默认的 `log.mining.strategy` 值已更改，现在是 `online_catalog`。由于绝大多数用户通常使用此策略，并且其性能通常优于 `redo_log_catalog`，因此我们认为此更改在 Debezium 3 中是有意义的。如果您的部署先前依赖于默认的 `redo_log_catalog` 策略，则在升级时需要显式地将 `log.mining.strategy` 添加到连接器配置中并指定值 `redo_log_catalog` (DBZ-3656)。
Oracle Ehcache 事务缓冲区实现
Debezium 3 引入了一个新的 Oracle 连接器事务缓冲区实现，基于 Ehcache，用于提供事务处理和事件数据的堆外存储。此新实现是对现有的 Java Heap、Infinispan Embedded 和 Infinispan Remote 缓冲区类型的补充。
要开始利用 Ehcache 实现，必须将 `log.mining.buffer.type` 设置为 `ehcache`。默认情况下，缓冲区类型为 `memory`，以使用 JVM 堆以获得最佳性能。
为了 Ehcache 库成功启动，必须提供一些额外的配置来显式配置缓存管理器维护的缓存。这些新配置选项是
-
log.mining.buffer.ehcache.global.config
-
log.mining.buffer.ehcache.transactions.config
-
log.mining.buffer.ehcache.processedtransactions.config
-
log.mining.buffer.ehcache.schemachanges.config
-
log.mining.buffer.ehcache.events.config
Debezium 使用 XML 创建 Ehcache 配置，因此这些配置提供了 XML 片段。
全局配置是可选的，它允许您提供有关持久化和其他 Ehcache 属性的详细信息，不包括指定 `
{
"log.mining.buffer.type": "ehcache",
"log.mining.buffer.ehcache.global.config": "<persistence directory=\"./data\"/>",
"log.mining.buffer.ehcache.transactions.config": "<resources><heap unit=\"entries\">256</heap><disk unit=\"B\">10485760</disk></resources>",
"log.mining.buffer.ehcache.processedtransactions.config": "<resources><heap unit=\"entries\">256</heap><disk unit=\"B\">10485760</disk></resources>",
"log.mining.buffer.ehcache.schemachanges.config": "<resources><heap unit=\"entries\">256</heap><disk unit=\"B\">10485760</disk></resources>",
"log.mining.buffer.ehcache.events.config": "<resources><heap unit=\"entries\">256</heap><disk unit=\"B\">10485760</disk></resources>"
}在此示例中，Ehcache 将维护堆和堆外存储的组合，始终保留最多 256 个堆条目并刷新到磁盘。磁盘缓存将存储在相对路径 `./data`。这意味着在使用基于磁盘的缓存时，您需要可用 的持久化存储卷。
这是一项新功能，目前处于实验阶段，因此我们非常欢迎您就如何改进它提出反馈 (DBZ-7758)。
Oracle 离线 RAC 节点刷新改进
在最近对 Oracle RAC 节点刷新策略进行的改进中，我们发现当数据库管理员将 Oracle RAC 节点置于离线状态时，会强制执行三秒延迟。由于 Oracle RAC 节点在离线状态下无法对重做日志执行任何写入操作，因此当节点保持离线状态时，这种三秒的延迟会引入不必要的延迟。
在 Debezium 3 中，只有在连接到 Oracle RAC 节点但刷新 SQL 操作不成功时，才会强制执行三秒延迟。这意味着，当数据库管理员将 RAC 节点置于离线状态进行维护时，连接器不会引入任何延迟开销（DBZ-8177）。
Oracle EXTENDED 最大字符串大小支持
Oracle 扩展字符串是一项功能，允许将字符数据的传统 4000 字节限制提高到 32K。这是通过应用数据库升级来完成的，将数据库参数 `max_string_size` 设置为 `EXTENDED`。然后，扩展字符串功能允许使用与 4000 字节或更小字符数据相同的 SQL 语法来处理高达 32K 的字符数据，而无需强制您使用基于 CLOB 的操作。
使用 Debezium 3，您现在可以将 Oracle 连接器与使用扩展字符串的数据库一起使用，并直接从事务日志捕获更改 (DBZ-8039)。由于扩展字符串实际上是在数据库级别上的 CLOB 操作，因此挖掘此类列类型需要将 `lob.enabled` 设置为 `true`。
由于此新功能处于实验阶段，我们非常希望能听到社区的任何反馈！
Oracle CLOB/BLOB 默认值支持
在某些情况下，Oracle 用户可能会定义具有 CLOB 或 BLOB 作为必需的表，使用 `EMPTY_BLOB()` 或 `EMPTY_CLOB()` 函数来定义未提供字段时的默认值。在之前的版本中，Debezium 没有评估这些特殊函数，因此此类列将被发出为可选而不是必选项。
从 Debezium 3 开始，当指定 `EMPTY_BLOB()` 或 `EMPTY_CLOB()` 默认值时，该字段将被发出为必选项。此外，该字段将包含相应的默认值，分别是空字节数组或空字符串 (DBZ-8248)。
PostgreSQL 连接器变更
PostgreSQL 复制槽创建超时
当 PostgreSQL 连接器首次部署时，其首要任务之一是如果复制槽尚不存在，则在数据库中创建它。复制槽对于连接器的工作方式至关重要，它促进了更改的捕获和分派给 Debezium。不幸的是，一些数据库操作会阻塞复制槽的创建，例如正在进行的事务，迫使连接器在等待事务完成时无限期地阻塞。对于短暂的事务，这通常不是问题；然而，对于长时间运行的事务，情况则完全不同。
为了改善此体验，添加了一个新的内部选项 `internal.create.slot.command.timeout`，默认值为 90 秒。如果在 90 秒内未能完成复制槽的创建，它将重试最多 `slot.max.retries` 次。一旦重试次数耗尽，连接器将抛出不可恢复的错误 (DBZ-8073)。
支持 PostgreSQL `PgVector` 数据类型
`pgvector` 扩展为 PostgreSQL 引入了向量搜索功能。该扩展引入了三种数据类型：`vector`、`halfvec` 和 `sparsevec`。
在 Debezium 3 中，所有三种数据类型都将像其他任何数据类型一样流式传输。每种数据类型都基于以下语义映射发出
-
`vector` 作为数字值数组
-
`halfvec` 作为数字值数组
-
`sparsevec` 作为带有维度数量和索引到值映射的结构体
在数据库中启用 `pgvector` 扩展后，无需额外配置。有关语义映射的更多详细信息，请参阅文档 (DBZ-8121)。
| 如果您在 3.0.0.CR1 之前的 Debezium 3 预览版本中使用了该版本，则模式名称已调整为更通用，以支持多个数据库供应商 (DBZ-8183)。如果您从之前的 Debezium 3 预览版本升级，请查看事件模式。 |
用于解码 PostgreSQL 逻辑消息的转换
PostgreSQL 的独特之处在于，您可以通过将逻辑消息直接写入 WAL 来实现 Outbox 模式，而无需创建 outbox 表，使用 `pg_logical_emit_message`。不幸的是，这些数据随后被发送到 Kafka，成为一系列字节，这对于希望获取结构化消息的消费者来说可能并不总是理想的。
Debezium 3 引入了一个新的 PostgreSQL 特定的转换器 `DecodeLogicalDecodingMessageContent`。此转换器专门用于将 `pg_logical_emit_message` 事件字节转换为消费者应用程序能够理解的结构化事件载荷。
考虑到以下配置
{
"transforms": "decode",
"transforms.decode.type": "io.debezium.connector.postgresql.transforms.DecodeLogicalDecodingMessageContent"
}在应用转换器之前，使用 `pg_logical_emit_message` 写入的事件的事件 `value` 将是
{
"op": "m",
"ts_ms": 1723115240065,
"source": {
...
},
"message": {
"prefix": "test-prefix",
"content": "eyJpZCI6IDEsICJpdGVtIjogIkRlYmV6aXVtIGluIEFjdGlvbiIsICJzdGF0dXMiOiAiRU5URVJFRCIsICJxdWFudGl0eSI6IDIsICJ0b3RhbFByaWNlIjogMzkuOTh9"
}
}应用转换器后，事件的 `value` 现在看起来像
{
"op": "c",
"ts_ms": 1723115415729,
"source": {
...
},
"after": {
"id": 1,
"item": "Debezium in Action",
"status": "ENTERED",
"quantity": 2,
"totalPrice": 39.98
}
}这样，您就可以安全地实现 Outbox 模式，而无需物理 outbox 表！(DBZ-8103)。
PostgreSQL 隔离级别支持
Reselect 后处理器改进
`ReselectPostProcessor` 是一个有用的工具，用于处理包含 TOAST 列（超大属性存储技术）的更改事件。默认情况下，当找到一个 TOAST 列并且它未被 SQL 操作修改时，Debezium 会用占位符填充这些字段，表示该值未提供，但也没有更改。许多数据类型使用此存储机制，包括 int/bigint 数组。使用 Debezium 3，这些 int/bigint 数组数据类型可以通过后处理器重新选择，以便始终填充这些字段，即使它们在 SQL 操作中未被更改 (DBZ-8212)。
SQL Server 连接器变更
信号和通知 MBean 名称更改
当连接器配置为多个数据库并产生多个任务时，SQL Server 的 JMX 信号和通知无法正常工作。为解决此问题，有必要更改信号和通知 MBean 的名称，以确保它们每个任务都是唯一的 (DBZ-8137)。
JDBC sink 连接器变更
JDBC sink 仓库迁移
JDBC sink 仓库已从 debezium-connector-jdbc 迁移到 debezium 主仓库 (DBZ-8008)。随着 Debezium 3 中 MongoDB sink 连接器的引入，这使得团队能够轻松地在我们的 sink 连接器之间共享通用合同。
今后，要为 JDBC sink 提出 pull 请求，请使用 Debezium 的主仓库，因为旧仓库已被存档并且仅为只读。
JDBC 在特定故障时重试刷新
JDBC sink 使用一组缓冲区来提高写入目标数据库的吞吐量。在某些用例中，这些缓冲区的刷新操作可能会遇到特定的异常，因为其他应用程序可能会锁定特定行或表。为了改善用户体验，添加了两个新的配置属性
flush.failure.max.retries-
定义发生刷新失败时重试的次数。
flush.failure.retries.wait.ms-
定义重试之间的等待毫秒数。
重试功能默认启用，最多尝试重试 5 次，每次重试之间延迟 1 秒。如果您更喜欢禁用重试，将 `flush.failure.max.retries` 设置为 `0` 将禁用此功能 (DBZ-7291)。
Debezium Server 变更
重大变更
- Debezium Server Kafka 接收器
-
当 Kafka Broker 不可用时，Debezium Server Kafka 接收器适配器可能会无限期等待。适配器中新增了一个可配置的超时时间，以便在达到超时时间时强制适配器失败。新的选项
debezium.sink.kafka.wait.message.delivery.timeout.ms默认值为 30 秒。如果默认值不能满足您的需求，请相应地进行调整（DBZ-7575）。 - Debezium Server RabbitMQ sink
-
Debezium Server RabbitMQ sink 适配器将所有更改发送到同一个单一流。虽然这在某些场景下可能有用，但它与其他的消息队列系统不符，在这些系统中，每个表都流式传输到自己独特的 Topic 或流。使用 Debezium 3，此逻辑已更改，默认情况下每个表都将流式传输到自己独特的流。设置 `debezium.sink.rabbitmqstream.stream` 时，可以启用将所有更改流式传输到同一流的旧行为 (DBZ-8118)。
支持自定义转换器类型
在 Debezium Server 的先前版本中，可用于头、键和值的转换器数量有限。这些包括 `Json`、`JsonByteArray`、`CloudEvents`、`Avro`、`Protobuf`、`Binary` 和 `SimpleString`。虽然这些通常能满足绝大多数用例，但并不罕见，有人可能在其环境中存在特定于其环境的独特要求，而这些要求超出了这些选项。
在此版本中，添加了一个新的 `ClientProvided` 转换器选项，它允许使用自定义的用户提供的实现来扩展头、键和值转换器 (DBZ-8040)。
改进 Kafka sink 的日志记录
当 Debezium 无法将记录发送到 Kafka 代理时，Kafka sink 适配器现在将记录记录键。这有助于了解特定记录存在什么问题，而无需增加运行时的日志详细程度 (DBZ-8282)。
Spanner 连接器变更
支持 32 位浮点数
Google Spanner 数据库引入了对 32 位浮点数据类型的支持。Debezium Google Spanner 连接器已调整以支持此新数据类型 (DBZ-8043)。
Vitess 连接器变更
其他修复和改进
在 Debezium 2.0 的开发过程中，进行了许多错误修复、稳定性更改和改进。总共有 202 个问题在此版本中得到修复。
非常感谢社区中为这个主要版本做出贡献的所有贡献者：Jordan Pittier、Kanthi Subramanian、Katerina Galieva、Kaustuv chakrabarti、Keri Harris、Kevin Rothenberger、Kosta Kostelnik、Lars M. Johansson、Liz Chatman、Lokesh Sanapalli、Lourens Naudé、Luca Scannapieco、M. Gökhan Akgül、Maithem、Marcelo Avancini、Mario Fiore Vitale、Mark Banierink、Mark Bereznitsky、Mark Ducommun、Mark Lambert、Martin Medek、Massimo Fortunat、Matt Vance、Mehmet Firat Komurcu、Michal Augustýn、Michal Pioun、Mickael Maison、Miguel Angel Sotomayor、Mike Kamornikov、Minh Son Nguyen、Mohamed El Shaer、Mostafa Ghadimi、My Lang Pangzi、Nancy Xu、Nick Golubev、Nikhil Benesch、Nir Levy、Olivier Boudet、Ondrej Babec、Oren Elias、Paul Cheung、Pengwei Dou、Peter Hamer、Piotr Piastucki、Plugaru Tudor、Poonam Meghnani、Pradeep Nain、Praveen Burgu、RJ Nowling、Rafael Câmara、Rajendra Dangwal、Raúl Estrada、René Kerner、Richard Harrington、Robert Roldan、Robin Moffatt、Roman Kudryashov、Ronak Jain、Russell Mora、Ryan van Huuksloot、Sahap Asci、Sean C. Sullivan、Sean Wu、Sebastiaan Knijnenburg、Selman Genç、Seo Jae-kwon、Seongjoon Jeong、Sergei Kazakov、Sergei Morozov、Sergey Eizner、Sergey Ivanov、Stavros Champilomatis、Stefan Miklosovic、Stein Rolevink、Stephen Clarkson、Subodh Kant Chaturvedi、Sun Xiao Jian、Sylvain Marty、Thomas Thornton、Théophile Helleboid、Tiernay、Tim Loes、Timo Wilhelm、Tomasz Gawęda、Tommy Karlsson、https://github.com/blcksrx Hossein[Torabi]、Tudor Plugaru、V K、Vadzim Ramanenka、Vaibhav Kushwaha、Vincenzo Santonastaso、Vincenzo Santonastaso、Vojtěch Juránek、Wu Zhenhua、Xianming Zhou、Xiaojian Sun、Xinbin Huang、Xuan Shen、Yang Wu、Yanjie Wang、Yashashree Chopada、Yohei Yoshimuta、Zheng Wang、Zhongqiang Gong、baabgai、david remy、einar-rt、ibnubay、ismail simsek、leoloel、martin、ming luo、moyq5、ruslan、sean、tison、tony joseph、tooptoop4、yohei yoshimuta、حمود سمبول，以及 蔡灿材！
关于 Debezium
Debezium 是一个开源的分布式平台，可以将现有数据库转变为事件流，使应用程序能够几乎即时地看到并响应数据库中已提交的每个行级更改。Debezium 构建在 Kafka 之上，并提供了 Kafka Connect 兼容的连接器，用于监控特定的数据库管理系统。Debezium 将数据更改的历史记录在 Kafka 日志中，这样您的应用程序可以随时停止和重新启动，并可以轻松地消费在未运行时错过的所有事件，确保所有事件都被正确且完整地处理。Debezium 在 Apache 许可证 2.0 下是 开源 的。
