Debezium 3.2.2.Final 带来了关键的稳定性改进,包括修复了在失败的临时阻塞快照期间潜在的数据丢失问题,解决了令人困惑的连接器启动错误,并增强了 Oracle LogMiner 的 JMX 吞吐量指标。

在本帖中,我们将深入探讨 Debezium 几个核心模块的改进,讨论任何新功能,并解释可能影响您升级过程的任何更改。一如既往,我们建议您阅读发布说明,以了解所有已修复的 bug、更新过程等。

新功能和改进

以下描述了 Debezium 3.2.2.Final 中所有值得注意的新功能和改进。如需完整列表,请务必阅读发布说明了解更多详情。

Debezium Core

Debezium for Oracle

Debezium Core

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Debezium for Oracle

最后批量处理吞吐量指标得到改进

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

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

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

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

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

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

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

  • 事务控制记录

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

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

其他修复

本次发布还有其他几项值得一提的重要修复

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

  • Quarkus-Debezium-Extension 与 Hibernate ORM 7 不兼容 DBZ-9193

  • 当字段的 schema 类型为 BYTES 时,ReselectColumnsPostProcessor 出现问题 DBZ-9356

  • MariaDB 无法解析使用 RENAME COLUMN IF EXISTS 语法的 ALTER TABLE DBZ-9358

  • 当表结构更改并抛出 ORA-01466 时,Oracle 无法重新选择列 DBZ-9359

  • 在创建操作中,单引号被双引号括起来 DBZ-9366

  • 使用归档日志仅模式时,挖掘上限计算错误 DBZ-9370

  • 由于 record.key 序列化错误,Kafka 生产者异常未正确记录 DBZ-9378

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

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

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

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

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

总结

Debezium 3.2.2.Final 总共解决了 24 个问题。更改列表也可以在我们的发布说明中找到。

非常感谢社区中所有辛勤工作的贡献者为这个版本付出的努力
Alvar Viana, Chris Cranford, Jiri Pechanec, Jonathan Schnabel, Luke Alexander, Marci, Mario Fiore Vitale, Olivier CHÉDRU, Robert Roldan, and Shyama Praveena S

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