在过去几个月里，团队一直非常忙碌，为 Debezium 2.3 的缩短发布周期做准备。我非常激动地宣布，下一版本已经到来，Debezium 2.3.0.Final 现已发布！
尽管发布周期缩短，但此版本充满了大量的新功能和改进。Debezium 2.3 包括了一个全新的通知子系统，重写了信号子系统以支持将信号发送到 Debezium 连接器的其他方式，引入了 JDBC 存储模块以在关系型数据库中维护 Debezium 状态，Vitess 分片处理的并行化，PostgreSQL 连接器的副本身份改进，一个全新的 Kubernetes Debezium Server Operator，对 PostgreSQL 连接器支持精确一次语义，以及对 Oracle 连接器的改进。
让我们花点时间来谈谈任何不兼容的变更以及所有这些改进，以及它们为何如此重要！
您也可以在 Debezium 2.3 的发行说明中找到完整的变更列表。
重大变更
我们通常会尽量避免在次要版本之间发生不兼容的变更，但有时这些变更确实是不可避免的，特别是当某个功能可能以实验性方式引入时。Debezium 2.3 引入了两项不兼容的变更，具体取决于您是从预览版本还是早期稳定版本进行升级。
PostgreSQL / MySQL 安全连接变更
Debezium for PostgreSQL 和 MySQL 可以配置为使用安全的 SSL 连接。对于 PostgreSQL，这可以通过配置 database.sslmode 来实现，而对于 MySQL，则可以通过 database.ssl.mode 来实现。
在 Debezium 2.3 中，此配置选项不再默认设置为 disable (PostgreSQL) 或 disabled (MySQL)，而是默认设置为 prefer (PostgreSQL) 和 preferred (MySQL)。这意味着，当尝试使用加密连接时，如果安全连接不可用，连接器将默认回退到使用不安全连接，除非另有配置。
JDBC 存储编码变更
Debezium 2.3.0.alpha1 引入了新的实验性 JDBC 存储模块。此存储模块默认使用 UTF-16 作为其默认编码；然而，大多数数据库默认更偏好 UTF-8。如果您从 Debezium 2.3.0.Alpha1 升级，Debezium 2.3.0.Beta1 及更高版本现在在使用 JDBC 存储模块存储数据时使用 UTF-8，以与典型的数据库默认值保持一致。
新功能和改进
Debezium 2.3 包含大量新功能和改进，包括以下内容：
Kubernetes 的 Debezium Server Operator
此版本引入了新的 Debezium Operator 的预览版本，提供了在 Kubernetes 中部署和管理 Debezium Server 实例的能力。Debezium Server 允许您将更改事件从数据源流式传输到各种消息基础设施。我们的目标是为希望利用 Kubernetes 进行可扩展性和高可用性部署的 Debezium 社区提供一个不依赖 Kafka 的替代方案。
目前，文档仍然很少，因为该 Operator 仍处于早期孵化阶段；但是，我们计划在未来的发布周期中对此进行改进。您可以在 GitHub 存储库中找到一个部署示例和对自定义资源规范的基本描述，作为短期参考。
我们目前不建议将此组件用于生产部署；但是，我们鼓励用户提供社区反馈。这些反馈对于评估该组件是否已准备好投入生产，或者是否仍有需要改进的地方以满足大家的需求将非常有价值。
新的通知子系统
Debezium 2.3 引入了一个全新的功能，称为通知，它允许 Debezium 发出事件，这些事件可以被任何外部系统消费，以了解 Debezium 生命周期各个阶段的状态。
通知事件表示为一系列键/值元组，其结构包含几个开箱即用的字段。以下是一个简单的通知事件示例。
{
"id": "c485ccc3-16ff-47cc-b4e8-b56a57c3bad2",
"aggregate_type": "Snapshot",
"type": "Started",
"additional_data": {
...
}
}每个通知事件都包含一个 id 字段，一个 UUID 用于标识通知，一个 aggregate_type 字段，该字段根据领域驱动设计概念与通知相关联，一个 type 字段，用于提供有关聚合类型的更多详细信息，以及一个可选的 additional_data 字段，该字段包含一个字符串键/值对的映射，其中包含有关该事件的附加信息。
目前，Debezium 支持两种通知事件类型：
-
初始快照的状态
-
增量快照的监控
初始快照通知
初始快照是在连接器首次启动时对现有数据的持续捕获。初始快照事件将具有值为 "Initial Snapshot" 的聚合类型，事件类型将包含以下三个逻辑值之一：
SKIPPED-
表示初始快照被跳过。
ABORTED-
表示初始快照被中止。
COMPLETED-
表示初始快照已成功完成。
以下是关于初始快照完成的通知示例：
{
"id": "5563ae14-49f8-4579-9641-c1bbc2d76f99",
"aggregate_type": "Initial Snapshot",
"type": "COMPLETED"
}增量快照通知
增量快照是在连接器主动流式传输更改时捕获一组配置表的现有数据。增量快照事件将具有值为 "Incremental Snapshot" 的聚合类型，类型将包含以下几个逻辑值之一：
STARTED-
指示增量快照已启动。
PAUSED (已暂停)-
指示增量快照已暂时暂停。
RESUMED (已恢复)-
指示已暂停的增量快照现已恢复。
STOPPED (已停止)-
指示增量快照已停止。
IN_PROGRESS-
指示增量快照正在进行中。
TABLE_SCAN_COMPLETED-
指示增量快照已为给定表完成。
COMPLETED-
指示增量快照已为所有表完成。
配置通知
Debezium 通知通过连接器的配置进行设置。以下示例展示了如何配置开箱即用的 Kafka Topic 或基于日志的通道。
{
"notification.enable.channels": "sink",
"notification.sink.topic.name": "debezium_notifications",
...
}{
"notification.enable.channels": "log"
}新的可扩展信号子系统
自 Debezium 1.x 引入增量快照功能以来，Debezium 一直支持信号的概念。信号很重要，因为它允许您提供元数据来指示 Debezium 执行特定任务，无论是将条目写入连接器日志还是执行即席增量快照。
在 Debezium 2.3 中，信号子系统被重构，引入了称为通道的概念，它代表了 Debezium 监视或监听并响应信号的媒介。在以前的版本中，所有连接器普遍支持一种通道，即数据库信号表。在此版本中，这些通道已统一，并提供以下开箱即用的选项：
-
数据库信号表
-
Kafka 信号主题
-
文件系统
-
JMX
但这还不是全部，信号通道接口是可扩展的，允许您编写自定义实现并轻松地将其提供给您的连接器。
JMX 信号和通知集成
Debezium 2.3 之前引入了新的信号通道和通知功能。此功能允许外部应用程序与 Debezium 轻松集成，发送信号以执行各种任务（如即席增量快照），并接收有关这些任务进度的通知。此版本在此功能基础上，支持通过 JMX 发送信号和接收通知。
发送信号
在此版本中，信号通道子系统已得到改进，支持通过 JMX 发送信号。从 jconsole 窗口，您现在可以看到连接器有两个新的子部分：通知和信号部分，如下所示：
新的 signals 部分允许您调用 JMX bean 上的操作以将信号传输到 Debezium。此信号类似于逻辑信号表结构，它接受 3 个参数：唯一标识符、信号类型和信号负载。以下是从 jconsole 中看到的示例：
接收通知
新的 notifications 部分允许您接收和响应 Debezium 通过 JMX bean 捕获的通知。Debezium JMX bean 会缓冲所有通知，以确保不会遗漏任何通知。以下是从 jconsole 中看到的示例：
| JMX bean 不会自动清除通知队列。为避免内存问题，请确保在处理完所有通知后调用通知 bean 上的 |
我们期待您就这种通过 JMX 集成 Debezium 信号和通知的新方式提供反馈。
新的 JDBC 存储子系统
Debezium 2.3 引入了一个新的存储模块实现，支持通过 JDBC 将模式历史记录和偏移量数据持久化到数据存储中。对于可能无法轻松访问持久文件系统的环境，这提供了通过远程持久存储平台进行存储的又一种选择。
为了利用此新模块，必须将以下依赖项添加到您的项目或应用程序中：
<dependency>
<groupId>io.debezium</groupId>
<artifactId>debezium-storage-jdbc</artifactId>
<version>2.3.0.Final</version>
</dependency>以下示例展示了如何通过 JDBC 存储模块配置偏移量或模式历史记录存储：
{
"offset.storage.jdbc.url": "<jdbc-connection-url>",
"offset.storage.jdbc.user": "dbuser",
"offset.storage.jdbc.password": "secret",
"offset.storage.jdbc.offset_table_name": "debezium_offset_storage"
}{
"schema.history.internal.jdbc.url": "<jdbc-connection-url>",
"schema.history.internal.jdbc.user": "dbuser",
"schema.history.internal.jdbc.password": "secret",
"schema.history.internal.jdbc.schema.history.table.name": "debezium_database_history"
}PostgreSQL 流式传输的精确一次传递
Debezium 传统上是一种至少一次传递（at-least-once delivery）解决方案，保证不会遗漏任何更改。精确一次（Exactly-Once）是 Apache Kafka 社区提出的一个提议，是 KIP-618 的一部分。该提议旨在解决生产者（源连接器）的一个常见问题：当生产者重试时，即使某个事件批次已被代理提交，它仍可能将该批次重新发送给 Kafka 代理。这意味着在某些情况下可能会发送重复事件，而并非每个消费者（接收器连接器）都能轻松处理这种情况。
Debezium 计划以分阶段的方式推出精确一次传递语义。在快照和流式传输方面存在特定的边界情况，这些情况因连接器而异。因此，Debezium 2.3 首先仅为 PostgreSQL 在其流式传输阶段添加了精确一次语义支持！
为了利用精确一次传递，无需进行连接器配置更改；但是，您的 Kafka Connect Worker 配置需要进行调整以启用此功能。您可以在 KIP-618 中找到新配置属性的参考。
| 如果您在同一个 Connect 集群上混合使用支持和不支持精确一次传递的连接器，则无法将 |
PostgreSQL 副本身份变更
Debezium 2.3 引入了一个新的 PostgreSQL 连接器功能，称为“自动设置副本身份”（Autoset Replica Identity）。
副本身份是 PostgreSQL 识别在数据库事务日志中捕获插入、更新和删除的列的方式。此新功能允许通过连接器配置来设置表的副本身份，并将设置此配置的责任委托给连接器在启动时完成。
新的配置选项 replica.identity.autoset.values 指定了一个逗号分隔的表和副本身份元组列表。如果表已具有给定的副本身份，并且该表包含在此配置中，则该身份将被覆盖以匹配此配置中指定的内容。PostgreSQL 支持多种副本身份类型，有关更多信息，请参阅文档。
在指定 replica.identity.autoset.values 时，该值是一个逗号分隔的值列表，其中每个元素使用 <fully-qualified-table-name>:<replica-identity> 的格式。下面是一个示例，其中两个表被配置为具有完整副本身份：
{
"replica.identity.autoset.values": "public.table1:FULL,public.table2:FULL"
}Oracle RAC 改进
连接到 Oracle RAC 安装时，必须指定 rac.nodes 配置属性，其中至少包含群集中所有节点的主机或 IP 地址。旧版本的连接器也支持一种变通的格式，允许包含每个节点的端口，因为群集中的并非所有节点都使用相同的端口。
Debezium 2.3 改进了 Oracle RAC 支持，它还认识到每个节点不一定使用相同的 Oracle Site Identifier (SID)，因此，SID 现在也可以包含在 rac.nodes 配置属性中以支持此类安装。
以下示例说明了连接到两个 Oracle RAC 节点，每个节点使用不同的端口和 SID 参数：
{
"connector.class": "io.debezium.connector.oracle.OracleConnector",
"rac.nodes": "host1.domain.com:1521/ORCLSID1,host2.domain.com:1522/ORCLSID2",
...
}其他修复
此版本中修复了许多错误并进行了稳定性改进，其中一些值得注意的包括：
-
Debezium Server 停止向 Google Cloud Pub/Sub 发送事件 DBZ-5175
-
Toasted varying character array and date array 没有被正确处理 DBZ-6122
-
升级到 Infinispan 14.0.11.Final 以修复 CVE-2022-45047 DBZ-6193
-
引入 LogMiner 查询过滤模式 DBZ-6254
-
部署多个连接器时，LOG_MINING_FLUSH 表上存在锁争用 DBZ-6256
-
确保连接器可以从超过一小时前的陈旧时间戳开始 DBZ-6307
-
Oracle 更改事件源信息块中的 rs_id 字段为 null DBZ-6329
-
将 JWT 身份验证添加到 HTTP 客户端 DBZ-6348
-
使用 pg_replication_slot_advance，它不受 PostgreSQL10 支持。DBZ-6353
-
log.mining.transaction.retention.hours 应引用最后一个偏移量，而不是 sysdate DBZ-6355
-
支持流式处理分片列表时的多个任务 DBZ-6365
-
skip.messages.without.change 的代码改进 DBZ-6366
-
Kinesis Sink - AWS 凭证提供商 DBZ-6372
-
Toasted hstore 未被正确处理 DBZ-6379
-
Oracle DDL shrink space for table partition 无法解析 DBZ-6386
-
SQL Server 的 __source_ts_ms r (read) 操作日期设置为未来 DBZ-6388
-
PostgreSQL 连接器任务因复制槽处于活动状态而无法恢复流式传输 DBZ-6396
-
根据 database.time_zone，不带时区的日期和时间值未正确持久化 DBZ-6399
-
MongoDB 连接器在无效的 resume token 时崩溃 DBZ-6402
-
快照步骤 5 - 读取捕获表的结构花费时间过长 DBZ-6439
-
只读 MySQL 连接器启动时出现 NPE DBZ-6440
-
Oracle 并行快照在使用多租户时未正确设置 PDB 上下文 DBZ-6457
-
[MariaDB] 添加对 userstat 插件关键字的支持 DBZ-6459
-
Debezium Server 无法从 Google Pub/Sub 错误中恢复 DBZ-6461
-
"忽略无效任务提供的偏移量" DBZ-6463
-
Oracle snapshot.include.collection.list 应在文档中以 databaseName 作为前缀。 DBZ-6474
-
Db2 连接器在发送通知时可能因 NPE 而失败 DBZ-6485
-
ExtractNewRecordState SMT 与 HeaderToValue SMT 结合使用会导致意外的字段名异常 DBZ-6486
-
当队列内存大小受限时，BigDecimal 失败 DBZ-6490
-
允许在 Debezium Sink Connector 配置中指定 schema DBZ-6491
-
ORACLE 表无法捕获，出现 runtime.NoViableAltException DBZ-6492
-
信号轮询间隔具有不正确的默认值 DBZ-6496
-
Oracle JDBC 驱动程序 23.x 抛出 ORA-18716 - 不在任何时区中 DBZ-6502
-
Alpine postgres 镜像应显式使用 llvm/clang 15 DBZ-6506
-
FileSignalChannel 未加载 DBZ-6509
-
在 Vitess 复制连接中利用 event.processing.failure.handling.mode DBZ-6510
-
MySqlReadOnlyIncrementalSnapshotChangeEventSource 在初始化期间强制使用 Kafka 依赖 DBZ-6511
-
Debezium 增量快照块大小文档不清楚或不正确 DBZ-6512
-
convertOracleIntervalDaySecond 中的错误值（负秒） DBZ-6513
-
Debezium 增量快照块大小文档不清楚或不正确 DBZ-6515
-
仅对某些错误使用错误处理模式 DBZ-6523
-
[PostgreSQL] LTree 数据未被流捕获 DBZ-6524
-
Oracle 连接器：特定组合下的快照失败 DBZ-6528
-
为 PartitionRouting 使用更好的哈希函数 DBZ-6529
-
快照中的表顺序不正确 DBZ-6533
-
开始为 Debezium Operator 发布夜间构建镜像 DBZ-6541
-
开始为 Debezium Operator 发布镜像 DBZ-6542
-
PartitionRouting 中未处理的 NullPointerException 将导致整个 Connect 插件崩溃 DBZ-6543
-
field.name.adjustment.mode 属性中的错误 DBZ-6559
-
Operator 在未指定 predicate 时设置了错误的 transformation.predicate 值 DBZ-6560
-
升级 MySQL JDBC 驱动到 8.0.33 DBZ-6563
-
升级 Google Cloud BOM 到 26.17.0 DBZ-6570
-
Kubernetes-Config 扩展由于 k8 devservice 启动而干扰 SSL 测试 DBZ-6574
-
启用了 Kafka 信号的 MySQL 只读连接器启动失败 DBZ-6579
-
Redis 模式历史记录在启动时可能失败 DBZ-6580
总共为本次发布修复了 138 个问题。非常感谢所有为本次发布做出贡献的社区成员：Andrei Isac、Angshuman Dey、Anil Dasari、Anisha Mohanty、Bertrand Paquet、Bob Roldan、Breno Moreira、Chris Cranford、Christian Jacob Mencias、David Beck、Frederic Laurent、Gong Chang Hua、Harvey Yue、Hidetomi Umaki、Hussain Ansari、Indra Shukla、Ismail Simsek、Jakub Cechacek、Jesse Ehrenzweig、Jiri Pechanec、Jochen Schalanda、Kanthi Subramanian、Katerina Galieva、Mario Fiore Vitale、Martin Medek、Miguel Angel Sotomayor、Nancy Xu、Nir Levy、Ondrej Babec、Oren Elias、RJ Nowling、René Kerner、Robert Roldan、Ronak Jain、Sergey Eizner、Shuran Zhang、Stephen Clarkson、Thomas Thornton、Tommy Karlsson、Tony Joseph、Vojtech Juranek，以及 蔡灿材！
下一步是什么？
随着 Debezium 2.3 的发布，我们的主要关注点将是协调针对 Debezium 2.3 的报告的错误修复，但主要精力将放在即将推出的 Debezium 2.4 的新预览版本上。
Debezium 2.4 计划包含大量更改，我们打算以分组方式处理这些更改，每个组分配一个优先级。与任何计划一样，优先级可能会发生变化，但以下是您期望的概要：
- 优先级 1
-
-
[核心] TimescaleDB 单条消息转换支持
-
[核心] 时区单条消息转换，方便使用 Debezium 时间类型
-
[核心] 初始快照通知
-
[MongoDB] 全数据库变更流支持
-
[MongoDB] 多任务部署指标支持
-
[Oracle] OpenLogReplicator 适配器支持
-
[Oracle] XML、LONG、RAW 和 LONG RAW 数据类型支持
-
[通用] 为其他连接器提供精确一次语义支持
-
[依赖] Apache Kafka 3.5.x 支持
-
- 优先级 2
-
-
[Operator] Debezium Operator 的后续步骤
-
[核心] 即席阻塞快照
-
[依赖] 使用 OpenTelemetry
-
- 优先级 3
-
-
[嵌入式引擎] 并行化支持
-
[MongoDB] 并行增量快照支持
-
[MySQL] 并行模式快照支持
-
这不是一个详尽的列表，而且相当有雄心。但考虑到 Debezium 2.3 的时间缩短，我们希望 Debezium 2.4 能有额外的几周时间来完成所有这些功能以及更多。路线图将在本周更新，以与 Debezium 2.4 及未来的计划保持一致。因此，如果您有任何想法或建议，请务必在 邮件列表或我们的 聊天 上与我们联系。
另外，我预计随着夏季的全面展开（对于我们北方的人来说），度假和应得的休息将在接下来的几个月里变得普遍。对于那些旅行或打算花些时间陪伴自己和家人的朋友们，请享受并注意安全！
下次再见……
关于 Debezium
Debezium 是一个开源的分布式平台，可以将现有数据库转变为事件流，使应用程序能够几乎即时地看到并响应数据库中已提交的每个行级更改。Debezium 构建在 Kafka 之上，并提供了 Kafka Connect 兼容的连接器，用于监控特定的数据库管理系统。Debezium 将数据更改的历史记录在 Kafka 日志中，这样您的应用程序可以随时停止和重新启动，并可以轻松地消费在未运行时错过的所有事件，确保所有事件都被正确且完整地处理。Debezium 在 Apache 许可证 2.0 下是 开源 的。
