尽管夏末将至,Debezium 团队带来了一个最新鲜的预览版本,包含一批新的改进和增强功能。通过 Debezium 3.3.0.Beta1,此版本为连接器生态系统带来了各种稳定性修复、性能优化和用户体验改进。让我们来看看这些是什么。

重大变更

任何新的主要软件版本通常都会带来一些破坏性更改。 Debezium 3.3.0.Beta1 版本也不例外,所以让我们来讨论一下您应该注意的主要变化。

Cassandra JMX 指标已更改

在早期版本的 Debezium for Cassandra 连接器中,每个 JMX 指标都暴露在 <logical-name> 域下的不同 MBean 中,下面是一个示例:

#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 Engine 类加载器更改

Debezium Engine 未设置线程上下文类加载器,这可能会使与 SpringBoot 等项目的集成变得复杂。现在已设置线程上下文类加载器,Debezium Engine 使用提供的类加载器加载所有类,而不仅仅是连接器(DBZ-9375)。

新功能和改进

以下描述了 Debezium 3.3.0.Beta1 中所有值得注意的新功能和改进。有关完整列表,请务必阅读 发行说明 以了解更多详细信息。

通知 Platform 用户管道在更改后重启

在使用 Debezium Platform 时,源、目标或其他资源可能会在两个或多个管道之间共享。对这些资源进行更改时,任何使用该资源的管道都必须重启才能使更改生效。

为了避免因管道重启而产生的意外结果,Debezium Platform 将在更改可能导致管道重启时通知用户,以便应用更新的配置(DBZ-9104)。

Platform Notify Restart

MongoEventRouter 支持自定义跟踪值

MongoEventRouter 现在支持将自定义跟踪配置值传递给路由器的能力,以便在事件载荷中可用(DBZ-9328)。可以提供以下配置选项:

属性 描述

tracing.span.context.field

包含序列化跨度上下文的 java.util.Properties 表示形式的字段的名称,默认为 tracingspancontext

tracing.operation.name

代表 Debezium 处理跨度的操作名称,默认为 debezium-read

tracing.with.context.field.only

当仅跟踪具有序列化上下文字段的事件时设置为 true,默认为 false

所有连接器的心跳处理得到改进

新的 ScheduledHeartbeat 实现已统一到各种连接器实现中(DBZ-9377)。这为所有连接器提供了通用的 API 和一致的心跳行为。

仅在需要时更改 PostgreSQL 发布

当 Debezium PostgreSQL 连接器配置为 publication.autocreate.mode 设置为 filtered 时,连接器会在每次连接器重启时发出 ALTER PUBLICATION 语句,以确保发布保持与连接器配置一致。

在某些情况下,当底层表正在进行 vacuum 或涉及长时间运行的 DDL 操作时,这将强制连接器等待直到这些任务完成,然后才能完成 alter。为了简化这一点,并只在绝对必要时阻塞,连接器现在在使用filtered模式时将配置的表列表与发布进行比较。只有当表列表存在差异时,才会执行 alter 命令,否则将跳过它以避免潜在的阻塞调用(DBZ-9395)。

连接器启动因模糊错误而失败

我们已解决一个导致连接器启动失败并出现误导性错误消息的问题,恢复了平稳启动,同时保留了改进的偏移量验证。

用户在连接器启动期间在一个角落案例中开始遇到此令人困惑的异常

org.apache.kafka.connect.errors.DataException: Invalid value: null used for required field: "schema", schema type: STRING

此模糊的错误消息没有提供关于实际问题的任何有用信息,使得故障排除几乎不可能。

该问题是我们最近对偏移量验证所做改进的一个意外后果。我们增强了逻辑,以便在源数据库中不再提供偏移量位置时提供更好的错误消息——这是一个有价值的功能,有助于诊断常见的操作问题。

然而,新的验证逻辑假设在连接器启动期间某些偏移量属性可用。实际上,这些属性要到连接器生命周期的后期才会被填充,导致验证过早失败并显示无用的错误消息。

我们已更新异常处理逻辑以:

  • 避免在启动时假设偏移量属性可用性

  • 保留对偏移量确实无效情况的增强验证

  • 在偏移量位置确实存在问题时提供有意义的错误消息

  • 允许正常启动进行,而没有误报

此修复确保您在没有启动中断的情况下获得增强的错误报告的好处(DBZ-9416)。

失败的即席阻塞快照后可能发生数据丢失

我们已解决一个关键问题,该问题可能导致即席阻塞快照出现问题时发生数据丢失,确保即使快照失败,您的流数据也能保持完整。

在运行即席阻塞快照时,表中出现无效数据会导致快照失败。不幸的是,此失败有一个严重副作用:快照期间发生的流事件将永久丢失。

这意味着,如果您的快照运行了几个小时才遇到错误数据,那么在连接器恢复正常流操作时,这几个小时内的所有实时更改都将被完全跳过。

阻塞快照现在可以通过以下方式优雅地处理故障:

  • 保留快照开始前立即的流位置

  • 在快照失败时自动从正确的位置恢复

  • 确保无论快照何时或为何遇到问题,都不会丢失任何数据

此改进使得阻塞快照在生产环境中更加可靠(DBZ-9337)。

Oracle 的最后一个批处理吞吐量指标得到改进

我们改进了 Oracle LogMiner 适配器中 LastBatchProcessingThroughput JMX 指标的准确性,让您能够更好地了解连接器的性能。

以前,此指标根据每个批处理中实际处理的捕获表事件的数量来计算吞吐量。虽然这似乎合乎逻辑,但在几种常见情况下会导致误导性的结果:

  • 数据库级别的过滤会减少已处理事件的数量,即使连接器仍在执行读取和评估这些过滤记录的工作

  • 事件流中的事务标记可能会扭曲数字,有时会严重低估实际处理负载

  • 各种配置设置会以不反映连接器真实性能的方式影响指标

该指标现在根据从 LogMiner 数据集中读取的 JDBC 行数来衡量吞吐量,无论这些行是否最终被

  • 在 JVM 中被您的配置过滤掉

  • 事务控制记录

  • 不匹配您的表或模式过滤器的事件

这让您对 Debezium 连接器在每个批处理处理窗口期间提供的原始处理能力有了更准确的了解(DBZ-9399)。

其他更改

  • Debezium 无法从连接错误中恢复 DBZ-7872

  • JdbcSchemaHistory 在恢复记录时未能处理数据分片 DBZ-8979

  • Debezium Quarkus Outbox 扩展无法与 Hibernate ORM 7 一起使用 DBZ-9193

  • Debezium Engine Quarkus 扩展:在示例存储库中添加快速入门 DBZ-9301

  • 添加 REST API 以验证连接 DBZ-9315

  • Oracle 连接器不支持大型 CLOB 和 BLOB 值 DBZ-9392

  • Oracle DDL 解析器异常 - DROP MATERIALIZED DBZ-9397

  • Debezium Platform OpenAPI 规范缺少返回的模式 DBZ-9405

  • Oracle 连接器不解析语法:DDL 中的 PARALLEL DBZ-9406

  • 增加允许的最大 JSON 字符串长度 DBZ-9407

  • task.management.timeout.ms 的错误默认值 DBZ-9408

  • LCR 刷新可能导致低水位线失效 DBZ-9413

  • Infinispan Protostream 与 Java 编译器 > 22 的兼容性 DBZ-9417

  • 增量快照期间上下文头被添加两次 DBZ-9422

总共有 30 个问题在 Debezium 3.3.0.Beta1 中得到解决。更改列表也可以在我们的 发行说明中找到。

Chris Cranford

Chris 是 IBM 的一名软件工程师,之前在 Red Hat 工作,他致力于 Debezium 项目,并每天都在深入研究 Oracle 和 Change Data Capture 的各个方面。他此前曾从事 Hibernate(领先的开源 JPA 持久化框架)方面的工作,并且继续为 Quarkus 做贡献。Chris 居住在美国北卡罗来纳州。

   


关于 Debezium

Debezium 是一个开源的分布式平台,可以将现有数据库转变为事件流,使应用程序能够几乎即时地看到并响应数据库中已提交的每个行级更改。Debezium 构建在 Kafka 之上,并提供了 Kafka Connect 兼容的连接器,用于监控特定的数据库管理系统。Debezium 将数据更改的历史记录在 Kafka 日志中,这样您的应用程序可以随时停止和重新启动,并可以轻松地消费在未运行时错过的所有事件,确保所有事件都被正确且完整地处理。Debezium 在 Apache 许可证 2.0 下是 开源 的。

参与进来

我们希望您觉得 Debezium 有趣且有用,并希望尝试一下。在 Twitter @debezium 上关注我们,在 Zulip 上与我们聊天,或加入我们的 邮件列表 与社区交流。所有代码都在 GitHub 上开源,因此请在本地构建代码,帮助我们改进现有连接器并添加更多连接器。如果您发现问题或有改进 Debezium 的想法,请告诉我们或 记录一个问题

版权所有 © Debezium 及其作者。保留所有权利。有关我们的商标详情,请访问我们的 商标政策商标列表。第三方商标属于其各自所有者,在此提及并不表示任何认可或关联。
×