今天,我很高兴地宣布 2.2 系列的第三个 alpha 版本 Debezium 2.2.0.Alpha3

此版本包含大量错误修复、改进、重大更改以及一些新功能,包括但不限于:可选的并行快照、服务器端 MongoDB 变更流过滤、增量快照的代理键,以及适用于 Cassandra Enterprise 的新 Cassandra 连接器,更多内容。

让我们花点时间深入了解一些新功能、改进和重大更改。

重大变更

我们通常会尽量避免任何破坏性更改,即使是在这种小版本发布中;然而,有时考虑到实际情况,破坏性更改是不可避免的。Debezium 2.2.0.Alpha3 包含一项破坏性更改

PostgreSQL 带时区日期时间数据类型被截断

已识别出(DBZ-6163),PostgreSQL 基于时区的列值,当毫秒和微秒部分为零 (0) 时,会被错误地序列化,导致字符串既不包含毫秒也不包含微秒的零值部分。

不会造成任何数据丢失!

需要注意的是,在此版本之前,在评估此类列的值时,消费者必须准备好解析这些基于字符串的时间值,因为它们可能缺少毫秒或微秒部分。实际上,这意味着事件模式不一致,有些将包含毫秒和微秒部分,而有些可能不包含,如果它们的源值具有 0 毫秒或 0 微秒。

这些基于字符串的时间值将被一致地发出,并用零 (0) 填充字符串时间的毫秒和微秒部分,即使源值既不包含毫秒也不包含微秒。

可选的并行快照

Debezium 的关系数据库初始快照过程一直是单线程的。这个限制主要源于确保跨多个事务数据一致性的复杂性。

从 Debezium 2.2 开始,我们正在添加一种新的、最初可选的方式,可以使用多个线程来执行连接器的、一致的数据库快照。此实现使用这些多个线程来并行执行表级别的快照。

为了利用这一新功能,请在连接器的配置中指定 snapshot.max.threads,当此属性的值大于 1 时,将使用并行快照。

使用并行快照的配置示例
snapshot.max.threads=4

在上面的示例中,如果连接器需要快照超过 4 张表,最多将有 4 张表并行快照。当一个线程完成处理一张表时,它将从队列中获取一张新表进行快照,并一直持续到所有表都被快照为止。

此功能被认为是孵化阶段,但我们强烈建议新部署的连接器尝试此功能。我们非常欢迎有关如何改进此功能的任何反馈。

MongoDB 服务器端变更流过滤

Debezium 目前订阅 MongoDB 变更流,并在连接器端评估事件是否相关。表面上看,这种方法在技术上没有问题,并且一直运行良好;然而,一位最近的贡献者解释了这一决定如何影响他们。

总的来说,当前过程有效地将所有 MongoDB 更改序列化并传输到连接器。如果您更改的量较少,您可能不会注意到此方法的问题;然而,在高吞吐量场景下,特别是当您只对变更流生成的数据子集感兴趣时,您很快就会发现这种方法效率低下。此外,如果您在 AWS 等云环境中运行连接器,在高吞吐量场景下,您很可能会看到成本增加。

通过将包含/排除列表过滤器的评估位置从连接器移到 MongoDB 服务器的变更流订阅,这为所有 MongoDB 连接器用户带来了许多优势。

通过减少连接器看到的事件数量,这会影响网络和 CPU 的利用率。当发送连接器仅因包含/排除过滤器而丢弃的事件时,会产生本可避免的网络使用。当连接器配置为完整的文档或预映像设置时,这会为网络增加更多的利用率,这是完全不必要的。此外,通过接收比连接器配置感兴趣的更多事件,这会导致连接器进行更多的处理,从而提高 CPU 利用率。

虽然网络和 CPU 利用率无论在哪种环境中都至关重要,但在操作基于云的环境时,这两个指标通常会受到更多关注,因为它们直接影响运营预算。用户应该会在 Debezium MongoDB 2.2 连接器上看到整体较低的网络和 CPU 利用率。

我们希望在未来的博客文章中分享更多关于此更改优势的细节,敬请关注!

增量快照代理键支持

Debezium 的增量快照功能取得了巨大成功。它提供了一种高效的方式来执行可恢复的一致数据快照,这对于数据量大的快照至关重要。

然而,增量快照在使用前有一些特定的要求必须满足。其中一项要求是所有被快照的表必须使用主键。您可能会问,为什么表没有主键,我们在这里不作辩论;但 suffice to say,这种情况比您想象的要常见。

使用 Debezium 2.2,只要有一个列是唯一的并且可以被视为增量快照的“代理键”,就可以在无键表上执行增量快照。

MongoDB 不支持代理键功能;仅限于关系型连接器。

为了在增量快照信号中提供代理键列数据,信号的 payload 必须包含新的代理键属性 surrogate-key

指定代理键的增量快照信号 payload 示例
{
  "data-collections": [ "public.mytab" ],
  "surrogate-key": "customer_ref"
}

在上面的示例中,将为表 public.mytab 启动增量快照,并且增量快照将使用 customer_ref 列作为生成快照窗口的主键。

代理键不能使用多个列定义,只能是单个列。

然而,代理键功能不仅适用于没有主键的表。在使用此功能处理有主键的表时,也有一系列优势

  1. 一个明显的优势是当表的复合主键由多个列组成时。查询为复合主键中的每个列生成一个析取谓词,其性能高度依赖于环境。将列数减少到单个列通常能普遍提高性能。

  2. 另一个优势是当代理键基于数值数据类型,而主键列基于字符类型数据类型时。关系数据库通常在进行数值比较时比字符比较更有效地进行谓词评估。在这种情况下,通过调整查询以使用数值数据类型,查询性能可能会更好。

其他修复

此版本中还有许多其他改进、错误修复和稳定性更改,其中一些值得注意的包括

  • 使用 snapshot.collection.include.list 时,关系型 schema 未正确填充 DBZ-3594

  • Debezium UI 应与 Quarkus 2.x 一起再次使用 fast-jar DBZ-4621

  • 创建基于 Cassandra 连接器的 Datastax 连接器 DBZ-5951

  • 添加支持以在 promotion 后 honour MongoDB 在变更流中的 read preference DBZ-5953

  • 为所有 Debezium Server sink 添加对 header 的支持 DBZ-6017

  • 当单个列上有多个索引时,GCP Spanner 连接器启动失败 DBZ-6101

  • MongoDB 重新连接时剩余尝试次数为负数 DBZ-6113

  • 支持 Mongo 增量快照中的键的 String 类型 DBZ-6116

  • Oracle 无法捕获名称中包含空格或非 ASCII 字符的表,因为它们必须被引用。 DBZ-6120

  • 在更改频率较低的 CDB 部署中,偏移量未前进到 PDB DBZ-6125

  • 允许 TestContainers 测试框架将 ConnectorConfiguration 公开为 JSON DBZ-6136

  • 快照期间,Oracle TIMESTAMP WITH TIME ZONE 发出的时间为 GMT,而不是指定时区 DBZ-6143

  • 将 impsort-maven-plugin 从 1.7.0 升级到 1.8.0 DBZ-6144

  • Debezium UI E2E 前端构建因损坏的 Node 16 tar 文件而随机失败 DBZ-6146

  • Debezium UI SQL Server 测试因代理启动缓慢而随机失败 DBZ-6149

  • 将 Quarkus 依赖项升级到 2.16.3.Final DBZ-6150

  • 删除硬编码的系统数据库排除列表,这些列表对于变更流不是必需的 DBZ-6152

  • RelationalSnapshotChangeEventSource 吞没了快照期间生成的异常 DBZ-6179

  • 为 MySQL 连接器的集成测试创建 SSL 场景 DBZ-6184

展望与下一步?

此外,我们即将完成 Debezium 2.2 的开发周期。假设没有意外问题,我们计划下周发布 Beta1,之后两周发布一个 Release Candidate。我们的目标是最晚在三月底或四月初完成 Debezium 2.2 的发布。

我们非常希望能听到您对我们的路线图、本次发布中的更改、或任何待处理或我们可能未提及的更改的反馈或建议。如果您有任何意见,请务必通过邮件列表或我们的聊天与我们联系。

此外,DevNexus 2023 会议将于四月初在亚特兰大举行,我有幸作为特邀演讲者,讨论 Debezium 和 CDC 模式。如果您有机会,请务必亲自参加我的演讲!

最后,请留意我们本月晚些时候发布的 2023 年第一期新闻通讯。我还会完成博客系列“Debezium for Oracle”,其中我将介绍 Oracle 连接器的性能、调试和常见问题解答。

下次见……

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