在本文中，我们将深入研究Debezium 3.0中的所有变化，讨论新功能，并解释可能对您的升级过程产生任何影响的所有可能变化。如往常一样，我们建议您阅读发布说明以了解所有修复的错误、更新程序等信息。

• 核心Debezium的变化
• MariaDB连接器的变化
• MongoDB连接器的变化
• MySQL连接器的变化
• Oracle连接器的变化
• PostgreSQL连接器的变化
• SQL Server连接器的变化
• JDBC sink连接器的变化
• Debezium Server的变化
• Spanner连接器的变化
• Vitess连接器的变化

Debezium 核心的变化

在本节中，将讨论影响 Debezium 核心的变化，并讨论这些变化如何影响所有用户。

需要 Java 17

• 此版本改变了构建和运行Debezium所需的Java要求。此外，此版本要求使用较新版本的Maven来从源代码构建Debezium。
• 所有Debezium连接器都需要Java 17的运行时基线。
• 如果使用Debezium Server、Operator或Quarkus Outbox扩展，需要Java 21的运行时基线。
• 如果您打算从源代码构建Debezium，则所有Debezium项目都需要Java 21和Maven 3.9.8或更高版本。如果使用Java 21之前的Java版本从源代码构建Debezium，则构建将失败，并报告需要Java 21或更高版本。
• 请参见下表，快速查看各组件所需的Maven和Java要求：

表 1. 要求

基于Kafka 3.8 构建

• 此版本转向 Kafka 3.8 作为我们测试和构建 Debezium 的基准。 Kafka 3.8 更改了许多需要适应 Debezium 使用的内部 API。

对于大多数用户来说，这一变化没有影响；但是，如果您要扩展 Debezium，请务必了解这些变化。

废弃的增量信号字段的删除

• 在Debezium 2.4中，增量快照信号有效载荷中的additional-condition字段已被废弃，被新的additional-conditions属性取代，允许按表指定条件。在此版本中，旧的additional-condition字段已被删除，不再支持。请确保更新可能引用了这个旧的废弃字段的脚本、工作流程或文档。

每个表的详细指标

• Debezium现在将开始跟踪基于每个关系表执行的单个创建、更新和删除操作的指标。对于一些连接器，如PostgreSQL和Oracle，这些新的详细指标还会跟踪每个关系表执行的截断操作。这在需要检测特定变更模式或者需要将详细信息应用于分析或可观察性堆栈的情况下非常有用，因为这些详细信息对于识别问题非常有价值。
• 对于升级到Debezium 3的用户，这些新的指标将自动捕获。它们使用Map<‍String, Long‍>的映射模式进行公开，其中键是表名，值是观察到的事件数量。新的指标名称包括NumberOfCreateEventsSeen，NumberOfDeleteEventsSeen，NumberOfUpdateEventsSeen和NumberOfTruncateEventsSeen

MariaDB连接器的更改

版本 11.4.3 支持

• Debezium 3将其基线支持转移到MariaDB的最新的非滚动版本11.4.3上。我们还密切关注MariaDB 11.6版本的发布周期，并计划在MariaDB 11.6稳定后引入向量数据类型支持。

MongoDB连接器的更改

MongoDB sink connector

• 在一年多之前的Debezium 2.2中，Debezium引入了第一个基于sink的连接器，并且我们很高兴地宣布，作为Debezium 3的一部分，我们还包含了另一个基于sink的连接器，用于MongoDB。
• 与JDBC sink关系连接器不同，需要安装额外的插件才能使用它，MongoDB sink连接器与MongoDB源连接器捆绑在同一部分中。因此，如果您已经安装或使用MongoDB源连接器，并且使用的是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的必填配置属性，它描述了一个逗号分隔的正则表达式列表，用于指定sink连接器将观察的主题。

MySQL连接器的改变

MySQL 9

• Oracle在2024年7月1日发布了MySQL 9.0的首个创新版本。我们很高兴地宣布，我们已经测试和验证了MySQL 9.0与Debezium 3.0及更高版本的兼容性和支持性。如果您遇到任何问题，请务必提交一个问题。

MySQL向量数据类型

• 在关系数据库中，最新添加的特性之一是引入了向量数据类型。除了对MySQL 9.0的支持之外，Debezium 3还引入了对新的VECTOR(n)数据类型的支持，该类型支持以二进制或列表格式的字符串表示的浮点值列表。
• 此外，MySQL语法已更新以反映对新的MySQL 9.0向量函数的支持。

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连接器配置。

默认的挖掘策略已更改

• 默认的log.mining.strategy值已更改为online_catalog。由于绝大多数用户通常使用此策略，并且它通常比redo_log_catalog策略表现更好，所以我们认为在Debezium 3中进行了这个更改。如果您的部署之前依赖于默认的redo_log_catalog策略，您将需要在升级时在连接器配置中显式添加log.mining.strategy并指定值为redo_log_catalog。

Oracle Ehcache事务缓冲实现

• Debezium 3引入了基于Ehcache的新的Oracle连接器事务缓冲实现，提供了事务处理和事件数据的堆外存储。这个新的实现添加到了现有的Java堆、Infinispan嵌入式和Infinispan远程缓冲类型中。
• 要开始利用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属性的详细信息，但不包括指定<‍cache‍>或<‍default-serializers‍>标签，这些标签是单独处理的。其他的单独缓存配置用于提供<‍cache‍>配置标签的内部XML部分，不包括<‍key-type‍>和<‍value-type‍>，这些由Debezium直接管理。

配置示例

{
  "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中。这意味着当使用基于磁盘的缓存时，您需要一个可用的持久性存储卷。

Oracle离线RAC节点刷新改进

• 在最近对Oracle RAC节点刷新策略的改进中，发现当数据库管理员将Oracle RAC节点下线时，会强制引入三秒的延迟。由于Oracle RAC节点在离线状态下无法对重做日志进行任何写操作，这三秒的延迟在节点保持离线状态时引入了不必要的延迟。
• 在Debezium 3中，只有在与Oracle RAC节点存在活动连接但刷新SQL操作失败时，才会强制执行三秒的延迟。这意味着当数据库管理员将RAC节点离线进行维护时，连接器不会引入任何延迟开销。

Oracle扩展的最大字符串大小支持

• Oracle扩展字符串是一项功能，允许将字符数据的传统4000字节限制提高到32K。这通过对数据库进行升级，将数据库参数max_string_size设置为EXTENDED来实现。扩展字符串功能允许使用与4000字节或更小字符数据相同的SQL语法来处理高达32K的字符数据，而无需强制使用基于CLOB的操作。
• 在Debezium 3中，您现在可以使用Oracle连接器与使用扩展字符串的数据库，并直接从事务日志中捕获更改。由于扩展字符串在数据库级别上实际上是CLOB操作，因此挖掘此类列类型需要将lob.enabled设置为true。

Oracle CLOB/BLOB默认值支持

• 在某些情况下，Oracle用户可能会定义表时将CLOB或BLOB字段定义为必需，并使用EMPTY_BLOB()或EMPTY_CLOB()函数来定义默认值，以便在字段未提供时使用。在先前的版本中，Debezium不会对这些特殊函数进行评估，因此这些列将被视为可选而不是非可选的。
• 从Debezium 3开始，当指定了EMPTY_BLOB()或EMPTY_CLOB()默认值时，该字段将被视为非可选。此外，该字段将包含适当的默认值，即空字节数组或空字符串。

PostgreSQL连接器的改变

PostgreSQL复制槽创建超时

• 当首次部署PostgreSQL连接器时，其中一个最初的任务是在数据库中创建一个复制槽（replication slot），如果该槽不存在。复制槽对连接器的工作方式至关重要，它有助于捕获和分发到Debezium的更改。不幸的是，某些数据库操作会阻塞复制槽的创建，比如进行中的事务，强制连接器无限期地等待事务结束。对于短暂的事务，这通常不是一个问题；然而，对于长时间运行的事务，情况就完全不同了。
• 为了改善这种情况，添加了一个新的内部选项internal.create.slot.command.timeout，默认为90秒。如果复制槽的创建在90秒内没有完成，它将重试，最多重试slot.max.retries次。一旦重试次数用尽，连接器将抛出一个不可恢复的错误。

支持PostgreSQL PgVector数据类型

• pgvector扩展为PostgreSQL引入了向量搜索功能。此扩展引入了三种数据类型：vector、halfvec和sparsevec。
• 在Debezium 3中，这三种数据类型将像任何其他数据类型一样进行流式传输。每种数据类型基于以下语义映射进行发射：
  • vector作为数字值的数组
  • halfvec作为数字值的数组
  • sparsevec作为一个结构体，包含维度数量和索引到值的映射。
• 在启用了数据库中的pgvector扩展后，不需要进行其他配置。
• 如果您在3.0.0.CR1之前使用了Debezium 3的预览版本，模式名称已经进行了调整，以更通用地支持多个数据库供应商。如果要从之前的Debezium 3预览版本升级，请查看事件模式。

转换解码PostgreSQL逻辑消息

• PostgreSQL在实现Outbox模式时独特之处在于，您可以通过使用pg_logical_emit_message将逻辑消息直接写入WAL，而无需创建一个outbox表。不幸的是，这些数据随后以一系列字节的形式发送到Kafka，这对于可能正在寻找结构化消息的消费者来说并不总是理想的。
• Debezium 3引入了一个新的专门针对PostgreSQL的转换器，称为DecodeLogicalDecodingMessageContent。此转换器专门用于将pg_logical_emit_message事件字节转换为消费应用程序能够理解的结构化事件负载。
• 给定以下配置：

{
  "transforms": "decode",
  "transforms.decode.type": "io.debezium.connector.postgresql.transforms.DecodeLogicalDecodingMessageContent"
}

在应用转换之前，使用pg_logical_emit_message编写的事件的值将为：

{
  "op": "m",
  "ts_ms": 1723115240065,
  "source": {
    ...
  },
  "message": {
    "prefix": "test-prefix",
    "content": "eyJpZCI6IDEsICJpdGVtIjogIkRlYmV6aXVtIGluIEFjdGlvbiIsICJzdGF0dXMiOiAiRU5URVJFRCIsICJxdWFudGl0eSI6IDIsICJ0b3RhbFByaWNlIjogMzkuOTh9"
  }
}

应用转换后，事件的值现在如下所示：

{
  "op": "c",
  "ts_ms": 1723115415729,
  "source": {
    ...
  },
  "after": {
        "id": 1,
        "item": "Debezium in Action",
        "status": "ENTERED",
        "quantity": 2,
        "totalPrice": 39.98
  }
}

因此，您可以安全地实现发件箱模式，而无需物理发件箱表！

PostgreSQL隔离级别支持

• 长期以来，PostgreSQL对快照隔离级别的支持一直是一个改进的方向，现在它已经实现了！一个新的连接器配置属性snapshot.isolation.mode，允许连接器在执行初始和临时阻塞快照步骤时控制使用的一致性。有四个隔离级别：串行化（默认值），可重复读、读已提交和读未提交。可以在文档中找到有关这些隔离级别以及它们如何与PostgreSQL一起使用的详细信息。

重新选择（Reselect）后处理器的改进

• ReselectPostProcessor是一个有用的工具，用于处理包含TOAST列（超大属性存储技术）的变更事件的填充。默认情况下，当发现TOAST列并且它未被SQL操作改变时，Debezium会用占位符填充这些字段，表示未提供值，但也未发生更改。许多数据类型使用这种存储机制，包括int/bigint数组。通过Debezium 3，这些int/bigint数组数据类型可以由后处理器重新选择，以便始终填充这些字段，即使它们在SQL操作中未发生更改。

SQL Server连接器的改变

信号和通知MBean名称的更改

• 当使用多个数据库生成多个任务配置连接器时，SQL Server的JMX信号和通知无法正确工作。为了解决这个问题，需要更改信号和通知MBean名称的命名，以确保它们在每个任务中是唯一的。

JDBC sink连接器的更改

JDBC sink存储库的重新定位

• JDBC sink存储库已从debezium-connector-jdbc迁移到debezium主存储库。在Debezium 3中引入了MongoDB sink连接器后，这使团队可以轻松地在我们的sink连接器之间共享公共契约。
• 未来，如果要为JDBC sink提出拉取请求，请使用主Debezium存储库，因为旧存储库已被存档，只能进行只读操作。

JDBC在特定故障上重试刷新操作

JDBC sink使用一组缓冲区来提高写入目标数据库的吞吐量。在某些情况下，由于其他应用程序锁定了特定行或表，这些缓冲区的刷新操作可能会遇到特定的异常。为了改善用户体验，添加了两个新的配置属性：

• flush.failure.max.retries
  • 定义刷新失败发生时的重试次数。
• flush.failure.retries.wait.ms
  • 定义重试之间等待的毫秒数。

重试功能默认启用，最多尝试重试5次，每次重试间隔1秒。如果您希望禁用重试，将flush.failure.max.retries设置为0即可禁用此功能。

Debezium Server的改变

Debezium Server Kafka Sink

• 当Kafka代理不可用时，Debezium Server Kafka sink适配器可能会无限期等待。新的可配置超时已添加到sink适配器中，当达到超时时，强制适配器失败。新选项debezium.sink.kafka.wait.message.delivery.timeout.ms的默认值为30秒。如果默认值不足以满足您的需求，请相应地进行调整。

Debezium Server RabbitMQ sink

• Debezium Server RabbitMQ sink适配器将所有更改发送到同一个单一流中。虽然这在某些场景下可能很有用，但它与其他代理系统不太匹配，其他代理系统中每个表都会被流式传输到自己独特的主题或流中。在Debezium 3中，这个逻辑已经改变，默认情况下，每个表将被流式传输到自己独特的流中。当设置debezium.sink.rabbitmqstream.stream时，可以启用将所有更改流式传输到同一个流中的传统行为。

支持自定义转换器类型

• 在之前的 Debezium Server 版本中，用于处理头部、键和值的转换器有限，这些转换器包括 Json、JsonByteArray、CloudEvents、Avro、Protobuf、Binary 和 SimpleString。虽然这些转换器通常能满足绝大多数用例的需求，但并不罕见，有人可能会有一些特定于他们环境的独特需求，这些需求超出了这些选项。
• 在这个版本中，新增了一个名为 ClientProvided 的转换器选项，它允许通过自定义的用户提供实现来扩展头部、键和值的转换器。

改进了 Kafka 接收器的日志记录

• 当 Debezium 无法将记录发送到 Kafka broker 时，Kafka sink 适配器现在将记录键进行日志记录。这有助于了解具体哪个记录存在问题，而不必要增加运行时的日志详细程度。

Spanner连接器的改变

支持 32 位浮点数

• Google Spanner 数据库引入了对 32 位浮点数据类型的支持。Debezium 的 Google Spanner 连接器已经进行了调整，以支持这种新的数据类型。

Vitess连接器的改变

空分片支持

• 在 Vitess 中，可能存在一个键空间没有任何表格的分片。Debezium for Vitess 已经改进了对这种用例的处理，现在可以优雅地处理这种没有错误的键空间。

继承分片纪元

• 添加了一个新的 Vitess 连接器配置属性，用于控制在重新分片操作后，新分片的纪元是否从其父分片继承。这个新的配置属性，vitess.inherit.epoch，默认为 false，不是默认启用的。

更多Debezium技术内容

更多Debezium技术请参考：

• Debezium技术专栏