Debezium 现在使用 Apache Kafka 4.0 构建和测试（DBZ-8875）。由于 Kafka 在 3.5 和 4.0 之间引入了多项 API 更改，我们强烈建议用户检查 Debezium 的 Kafka 兼容性支持矩阵。

Debezium 已从 RHOSS Sonatype 基础架构迁移到 Maven Central（DBZ-9025）。为了确保您获取最新的 snapshot 构建，请使用我们夜间文档页面上的更新链接，该页面位于此处。请注意，由于当前的 API 限制，这些链接每天只更新一次，尽管我们全天向 Maven Central 推送多个 snapshot 构建。

Debezium 在 Debezium 2.5 中引入了 `delete.tombstone.handling.mode` 配置选项，作为 DBZ-6907 的一部分，并将 `drop.tombstones` 和 `delete.handling.mode` 标记为弃用。我们认为已经有足够的时间移除旧的配置选项，因此 Debezium 3.2 不再使用 `drop.tombstones` 或 `delete.handling.mode`。如果您的连接器配置继续使用这些弃用的选项，请将您的配置调整为使用 `delete.tombstone.handling.mode`（DBZ-6068）。

某些 DDL 事件，如 `TRUNCATE` 和 `REPLACE`，曾存储在 Debezium 的内部 schema history topic 中。Debezium 不需要这些类型的语句来表示 schema 演进，并且在未来将不再捕获到内部 schema history topic 中（DBZ-9085）。

Debezium AI 模块中可用的新 `FieldToEmbedding` 转换使用了配置选项名称中的前缀字符串。此前缀是多余的，因此我们决定移除该前缀（DBZ-9056）。

当 Debezium MySQL 连接器配置为除 `when_needed` 之外的任何 `snapshot.mode` 且二进制日志位置不可用时，连接器会记录一个警告，表明连接器将从日志中最后可用的位置恢复。然而，当连接器进入流式处理阶段时，它会立即失败，报告找不到二进制日志位置。我们改进了此行为，使其在验证阶段就抛出错误，从而与其他连接器的行为保持一致（DBZ-9118）。

Debezium for Oracle 连接器不仅支持与 Oracle Wallet 的 TLS 连接，您还可以使用 JKS。要使用 JKS，需要特殊的连接器配置，以便为 Oracle JDBC 驱动提供正确的信息。现在已为社区正确记录了这一点（DBZ-8075）。

Debezium IBMi 连接器曾明确编码使用 Avro schema 命名调整器（DBZ-9183）。现在不再是这样，该选项现在是可配置的，并且与其他连接器的行为相同。

在 Debezium for IBMi 的先前版本中，如果连接器所需的日志文件不可用，它将从下一个可用文件继续读取。这可能导致潜在的静默数据丢失。行为已更改，连接器将像其他连接器一样，在必需的日志文件不存在时报告错误（DBZ-8898）。

在 Debezium 的先前版本中，schema history 恢复是在连接器的主要启动线程中执行的。当 schema history 非常大时，此恢复可能需要一段时间才能完成。

对于 Kafka Connect 等环境，这可能导致 Kafka Connect 错误地表示连接器的当前状态。例如，如果连接器先前失败并正在重新启动，Kafka Connect 将继续报告连接器处于 `FAILED` 状态，尽管连接器已启动并运行，但目前正在恢复 schema history topic。这个细微但重要的细节如果没有查看连接器日志将很难分离。

为了解决这个问题，Debezium 会将 schema history topic 的恢复延迟到 Debezium 协调器线程启动时。这使得 Kafka Connect 运行时能够更快地返回并更新运行时的连接器状态，以准确表示连接器的状态，而不会受到长时间 schema history 恢复的影响（DBZ-8562）。

一位社区成员在 Kafka schema history 实现中发现了一个性能优化机会。在恢复过程中，一些步骤被执行的频率高于必要，导致 CPU 利用率升高。为了优化这一点，其中一些步骤只在每次 schema history 恢复时调用一次。这减少了 CPU 利用率以及在 schema history 恢复过程中与 Kafka Broker 的网络通信（DBZ-9098）。

在之前的版本中，Debezium 会将 `SnapshotCompleted` 指标设置为表示快照已完成，即使在快照因配置或偏移量可用而被跳过的情况下。这对于一些用户来说具有误导性，因此引入了一个新的 `SnapshotSkipped` 指标，以澄清何时执行并完成快照，以及何时因不需要而跳过快照（DBZ-8610）。

如果配置得当，Debezium 会在删除后立即将 tombstone 事件注入变更事件流。然而，如果连接器重新启动，并且只有删除事件被写入 Kafka topic，连接器在重新启动时不会重新发出 tombstone，因为 tombstone 是合成的。

从 Kafka Broker 的角度来看，这不会产生任何功能影响。然而，对于依赖 tombstone 存在以实现特定行为的消费者来说，这可能会有问题。

由于消费者通常依赖扁平化的事件结构而不是 Debezium 的分层事件 payload，`ExtractNewRecordState` 转换包含了一个新的 `delete.tombstone.handling.mode` 配置属性选项，名为 `delete-to-tombstone`。此选项强制转换将删除事件转换为 tombstone。这允许您禁用 tombstone 并使用转换将删除转换为 tombstone，确保 topic 中有一个 tombstone 用于压缩，更重要的是，以便消费者可以执行其依赖 tombstone 的行为（DBZ-9022）。

在 Debezium 3.1 中，我们引入了一项变更，用于集中记录敏感信息。不幸的是，此变更导致了性能回归，导致多种代码路径的性能下降。

此变更已被撤销，并替换为一项新的实现，该实现保留了集中式日志记录的意图，同时恢复了之前的性能（DBZ-8879）。

在空闲活动期间，Debezium 连接器将继续报告 LagBehindSource JMX 指标作为最后计算的值，因为该值仅在新更改收到时更新。对于某些环境而言，如果不了解空闲或低活动窗口，这会不太理想或不直观。

Debezium 3.2 引入了一个可以通过 JConsole 或其他 JMX 集成触发的新选项，通过调用新的 `resetLagBehindSource` 函数来重置当前的 `LagBehindSource` 指标（DBZ-8885）。

当 JMX 指标 MBean 注册失败时，大多数情况下是因为已经有一个 MBean 以该名称注册。这可能由于多种原因发生，包括先前的任务未能优雅停止，或两个共享相同 `topic.prefix` 的连接器之间的配置错误。

不幸的是，日志消息没有提供足够的信息来知道是哪个 MBean 和连接器出现了故障。为了解决这个问题，将在 MBean 注册失败时记录 JMX MBean 名称，以便更容易确定受影响的确切连接器部署（DBZ-8862）。

对于 PostgreSQL 用户，在捕获分区表的更改时，更改是使用分区名称而不是基本表发布的。如果您想将跨分区的更改重新组合到一个主题中，这通常需要使用 `ByLogicalTableRouter` 将所有分区的事件路由到一个主题，或者在数据库层面手动调整发布。

Debezium 3.2 旨在通过新的 `publish.via.partition.root` 属性来简化这个问题。默认情况下，此选项为 `false`，表示除非手动调整发布，否则事件主题将使用分区名称而不是基本表。但是，您可以将此属性设置为 `true`，Debezium 将确保使用 `publish_via_partition_root` 功能创建发布，以便来自各个分区表的事件将使用单个基本表名发布（DBZ-9158）。

在使用 Debezium for PostgreSQL 连接器并配置为只读模式时，发现了一个回归问题。不幸的是，连接器会尝试 CREATE 或 ALTER 连接器的发布，即使它被配置为只读模式，导致 SQL 异常。我们已经纠正了此行为，Debezium 在只读模式下运行时将不再尝试创建或修改发布（DBZ-8743）。

Debezium for Oracle 引入了一个新的适配器实现，该适配器使用数据库的内存缓冲区在关系数据库上缓冲事务，而不是依赖 JVM 堆或堆外缓存实现（DBZ-8924）。

要开始使用新适配器，需要调整连接器配置，如下所示：

这个新的适配器实现基于 Oracle LogMiner 的 `COMMITTED_DATA_ONLY` 模式。此模式强制 Oracle LogMiner 使用数据库可用内存来缓冲事务，并且仅向 Debezium 提供已提交的更改。由于 Debezium 只接收已提交的更改，因此连接器可以在读取它们时立即分派更改，这避免了复杂的内存大小调整要求以及处理因保存点或约束违规而导致的局部回滚的需要。

由于 Oracle LogMiner 现在负责缓冲事务直到观察到提交，Oracle LogMiner 将依赖数据库的内存来处理此阶段性要求。这直接意味着此阶段性要求仅与 `PGA_AGGREGATE_LIMIT` 数据库管理员配置的 Oracle 数据库实例参数一样强大。当事务的内存需求超过此限制时，Oracle 将拒绝缓冲事务并抛出连接器错误。这可以通过提高配置的限制、完全删除限制或调整事务大小以使其符合此 Oracle 限制的边界来解决。

Oracle LogMiner 适配器提供了多种方法来排除事务，通过显式将过滤器传递给数据库查询，以排除或仅包含特定数据库用户执行的事务。在此版本中，我们添加了一个基于 Oracle LogMiner 字段 `CLIENT_ID` 的额外有趣过滤器条件，您可以通过此字段的值选择包含或排除更改（DBZ-8904）。

可以使用以下配置属性

与其他包含/排除配置属性一样，这些属性是互斥的。

在 Debezium 3.1 中，我们根据DBZ-8665引入了一项变更，旨在恢复 Debezium 2.7.0.Final 处理约束冲突或回滚保存点操作时的性能。虽然此变更成功降低了 Debezium 3.0 至 3.0.7 处理此类事件引起的延迟，但我们发现即使是 Debezium 2.7 的性能也总体不尽如人意。

我们已实现对事务缓冲解决方案的全面重构，以更有效地处理约束冲突和回滚保存点（DBZ-8860）。

在使用基于堆的缓冲时，我们将处理此类事件所需的时间缩短了近 90%，同时将堆外缓冲的时间复杂度降低了 97-99%。除了降低时间复杂度外，我们在处理这些事件时还降低了整体 CPU 使用率，以符合预期。

在添加 hybrid 挖掘策略之前，Debezium Oracle LogMiner 实现包含一个特定条件，用于包含 LogMiner 无法解析表名的表的事件。这种情况发生在对象 ID 和重做条目中的版本与在线数据字典不匹配时，这在执行特定 DDL 操作后会发生。

包含这些更改，特别是当用户执行批量操作且 LogMiner 无法解析表名时，会增加延迟、连接器开销，仅用于连接器记录未知表。鉴于仅仅为了记录而导致的性能下降，我们选择在后续的数据获取中省略包含这些事件（DBZ-8926）。

我们还发现了另一个性能瓶颈，这次是在使用 hybrid 挖掘策略处理批量事件时，LogMiner 在对象 ID/版本不匹配时无法解析表名。hybrid 策略旨在处理这种情况并回退到 Debezium 的关系模型来解析表名；然而，尽管使用了缓存，但对于批量操作的缓存查找的成本开销却非常高。

为了降低成本并提高未知表上批量操作的吞吐量性能，我们对查找进行了重构，从而显著提高了吞吐量，使得批量操作能够更高效地处理，并降低了整体 CPU 利用率（DBZ-8925）。

当使用 Debezium for Oracle LogMiner 缓冲适配器时，当观察到部分回滚时，日志条目不包含对调试有用的关键信息。Debezium 3.2 现在包含了与部分回滚重做条目关联的事务标识符和系统更改编号（DBZ-8944）。

当一个事务在两个或多个日志挖掘步骤中被挖掘时，第一个步骤之后的任何事件都返回 `UNKNOWN` 用户名。这有可能导致配置的用户排除未正确应用，并且错误地发出了事件。

在 Debezium 3.2 中，我们改进了此工作方式，以便即使事务在多个步骤中被挖掘，也能正确收集用户名属性。此改进避免了将事务分派到您的 Kafka topic，但目前事务将继续被缓冲（DBZ-8884）。

Debezium JDBC sink 提供多种可配置的钩子，包括定义特定部署的 `TableNamingStrategy` 或 `ColumnNamingStrategy` 实现的选项。然而，这些实现无法获取连接器部署的完整配置，这使得这些钩子比预期的限制性要小。

在 Debezium 3.2 中，这些策略实现提供了一个新的 `configure` 方法（DBZ-7051），如下所示：

为了向后兼容，此方法被定义为默认且无实现，因此在不需要此配置步骤的地方不需要进行代码更改。

Debezium JDBC sink 连接器可以使用以下两种缓冲算法之一。

默认情况下，源中的每次更改都会在目标系统中产生一个匹配的 SQL 更改。此算法依赖于为每个目标表维护两个存储桶，并根据该 topic 中观察到的事件序列定期刷新这些存储桶。

第二种算法称为缩减缓冲区，其中分析和缩减批次中的所有事件，以便连接器在整个批次中执行最少数量的 SQL 操作。例如，如果在一个批次中，对同一表有一个插入、一个更新和一个删除，缩减缓冲区算法会计算对于该事件的主键不需要任何写入。

根本问题在于，尽管缩减缓冲区应该只在批次结束时刷新，但刷新是按照连接器使用默认算法操作的方式进行的，这会导致性能不佳。使用前面的示例，回归导致缩减缓冲区执行 2 个 SQL 操作而不是 0 个 SQL 操作。

这已在 Debezium 3.2 中修复，缩减缓冲区现在的性能会显著提高（DBZ-8982）。

`heartbeat.action.query` 配置选项是许多 Debezium 连接器中广泛使用的功能。当非捕获表上出现高活动场景时，通常会使用此选项，它保证在捕获表中有一个定期事件，以防止偏移量过时。从 Debezium 3.2 开始，Debezium for Informix 连接器现在支持此配置选项（DBZ-9081）。

IBM 为 IBM iSeries 数据库的 V7R5+ 和更高版本的 V7R4 版本提供对 `BOOLEAN` 数据类型的支持。在先前版本中，如果表包含布尔数据类型，这将导致 Debezium for IBMi 连接器硬失败。

在 Debezium 3.2 中，现在可以在不抛出异常的情况下捕获 `BOOLEAN` 数据类型（DBZ-7796）。

`decimal.handling.mode` 配置属性指定连接器如何处理连接器特定数据类型的浮点值。在 Debezium for IBMi 连接器的先前版本中，此配置属性未被遵循。

Debezium 3.2 引入了对 `decimal.handling.mode` 的支持，允许您指定浮点值是否被序列化（DBZ-8301）。此配置属性可以配置为以下三个值之一：

新的配置属性 `vitess.grpc.default.load.balancing.policy` 使连接器能够控制其连接的负载均衡方式。例如，可以将该属性设置为 `pick_first`（默认值）或 `round_robin`（DBZ-9014）。

`DebeziumEngine` 接口提供各种功能，包括知道连接器或任务何时启动或停止。然而，由于连接器是异步操作的，因此了解连接器何时进入轮询阶段以执行特定用户驱动的逻辑可能很有用。

为了解决这个问题，在 `ConnectorCallback` 合约中添加了两个新方法（DBZ-8948）

现在，在设置 `DebeziumEngine` 实例时，`ConnectorCallback` 提供的实现可以根据需要包含在这些生命周期状态变化期间调用的逻辑。

Debezium 源连接器旨在将 JSON 数据类型值作为 `io.debezium.data.Json` 语义类型发出，该类型将 JSON 值编码为字符串。然而，当使用 Debezium Server 将更改 sink 到 Milvus 时，这可能不总是期望的结果。

已添加了一个新的配置属性 `debezium.sink.milvus.unwind.json`，它可以设置为 `true` 或 `false`（默认值）。当此属性设置为 `true` 时，JSON 字符串值将表示为 `JsonObject`（DBZ-8909）。

Debezium 源连接器通常配置有心跳事件，以便在低活动期间的任何时候，源的偏移量信息都不会过时。然而，对于像 Redis 这样的某些 sink，将这些心跳事件传递给 sink 目标是无用的。

已添加了一个新的配置属性 `debezium.sink.redis.skip.heartbeat.messages`，它可以设置为 `true` 或 `false`（默认值）。当此属性设置为 `true` 时，Redis sink 将跳过向 Redis 目标发送心跳事件；但是，心跳事件将继续影响陈旧偏移量的管理（DBZ-8911）。

Qdrant 是一个开源的、高性能、低延迟的向量数据库，旨在高效地存储和搜索高维向量。它也与来自 OpenAI、Hugging Face 或 sentence-transformers 等模型的嵌入很好地配合。Qdrant 的一些用例包括但不限于聊天机器人、文档搜索、图像/视频相似度等。

在 Debezium 3.2 中，我们为 Debezium Server 引入了一个新的 sink 适配器，允许您消费更改并将其放入 Qdrant。要开始使用 Qdrant sink，请在应用程序属性中按如下方式配置 Qdrant：

您可能需要大量的可选配置。请参阅在线文档以获取更多详细信息。

为了使用 Azure Event Hubs 进行压缩 topics，消息键对于保持 topic 大小合理并方便重新播放 topic 消息至关重要。Debezium 3.2 使 Azure Event Hubs sink 的行为与 Kinesis 等其他 sink 保持一致，后者基于记录的键选择分区（DBZ-9195）。

当变更事件在转换链中被修改时，转换可能会选择向事件添加 header。不幸的是，在 Debezium 的先前版本中，这些 header 没有被复制到 NATS Jetstream。

从 Debezium 3.2 开始，在转换链期间添加到事件的所有 header 现已复制到 NATS Jetstream。无需配置或更改，只需更新到 Debezium 3.2.0.Final 即可自动完成（DBZ-9171）。

当 PubSub sink 消费大量更改时，PubSub sink 在发送批次数据时可能超出最大允许的 10MB 批次阈值，导致交付问题。为了解决这个问题并简化用户体验，`batch.request.byte.threshold` 已减小到 9.5mb。这与其他与 Google PubSub 交互的连接器保持一致，以保证批次交付而不超出最大阈值（DBZ-9144）。

使用 Redis sink 时，您可能希望 sink 在 SSL 连接过程中验证主机名。这可以通过在 sink 配置中提供 `ssl.hostnae.verification.enabled` 选项来实现，以便执行主机验证。当使用 Redis offset 和 schema history 实现时，此选项也可用（DBZ-9042）。

Debezium 3.2 引入了几个新的配置选项，允许为 Redis sink 使用自定义密钥/信任库详细信息（DBZ-9082）。以下显示了这些新选项的示例：

我们在 Debezium Management Platform 界面中为转换添加了多项新功能（DBZ-8328），包括：

我们非常希望您对新的导航工作流和转换方面的改进提供反馈。

Debezium 的通知子系统是允许 Debezium 通知感兴趣的消费者连接器状态更改的强大方式。Debezium 3.2 在将 Debezium Server 部署到 Kubernetes with Debezium Platform 时引入了对通知的基本支持。此基本支持侧重于提供日志通道，以便在 Debezium Server pod 日志中观察通知（DBZ-9046）。

我们为使用 `FieldToEmbedding` 转换的 Debezium AI Ollama 模型集成添加了一个新的配置属性 `ollama.operation.timeout.ms`。此配置属性指定模型操作允许执行的毫秒数，之后请求将超时。默认情况下，转换等待 15 秒，但可以相应调整（DBZ-8908）。