距离我们上次发布 Debezium 2.4 系列的预览版本已经将近两周了,我很高兴地宣布该系列的下一个版本,Debezium 2.4.0.Beta2

虽然 Beta 版本通常侧重于稳定性和错误修复,但此版本包含许多值得注意的改进和新功能,包括 Oracle 的新 Oracle OpenLogReplicator 摄取方法、用于处理时区转换的新单消息转换器、MongoDB 的自定义身份验证支持、MongoDB 聚合管道的可配置顺序,以及对 MongoDB 7 的支持。

让我们花点时间更详细地深入了解所有这些新功能、改进和更改。

使用 OpenLogReplicator 进行 Oracle 摄取

Debezium 的 Oracle 连接器传统上包含两个适配器,一个用于 Oracle XStream,另一个用于直接与 Oracle LogMiner 集成。虽然每个适配器都有其优点,并且在数据类型和用例的功能和支持方面都相当成熟,但我们希望探索一种全新的捕获变更的方式。

Debezium 2.4.0.Beta2 引入了一个新的、实验性的 Oracle 摄取适配器,它基于 OpenLogReplicator。该适配器直接与 OpenLogReplicator 进程集成,以类似 XStream 实现作为 Oracle GoldenGate 客户端的方式创建变更事件。

OpenLogReplicator 是一个独立进程,必须运行在 Oracle 数据库服务器上,或者可以独立于数据库服务器运行,但需要通过 TCP/IP 直接与数据库通信,并对 Oracle redo 和 archive 日志文件具有直接读取访问权限。OpenLogReplicator 也不提供任何预编译的二进制文件,因此代码必须直接从源代码构建,或者部署在可以远程通过文件共享访问数据库及其文件的 容器镜像 中。

安装 OpenLogReplicator 后,设置需要以下步骤:

  • 配置 OpenLogReplicator 的配置文件 OpenLogReplicator.json

  • 配置 Oracle 连接器以使用 OpenLogReplicator 适配器。

目前,Debezium 的 Oracle 连接器要求 OpenLogReplicator 配置使用非常特定的设置,以便数据以正确的序列化方式传输到连接器。 示例配置 展示了 Debezium 正确摄取数据所需的关键配置参数。

当 OpenLogReplicator 配置完成后,您应该会看到 OpenLogReplicator 启动时显示以下内容:

OpenLogReplicator v1.2.1 (C) 2018-2023 by Adam Leszczynski (aleszczynski@bersler.com), see LICENSE file for licensing information, arch: x86_64, system: Linux, release: 6.4.11-200.fc38.x86_64, build: Debug, modules: OCI Probobuf
adding source: ORACLE (1)
adding target: DBZ-NETWORK (2)
writer is starting with Network:0.0.0.0:9000 (3)
1 OpenLogReplicator.json 中配置的源别名。
2 OpenLogReplicator.json 中配置的目标别名。
3 OpenLogReplicator 正在监听的主机和端口。

最后,要配置连接器,请设置以下连接器配置选项:

{
  "database.connection.adapter": "olr",
  "openlogreplicator.source": "<source-alias>", (1)
  "openlogreplicator.host": "<host>", (2)
  "openlogreplicator.port": "<port>" (3)
1 将在 OpenLogReplicator.json 配置中定义的源别名,以供使用。
2 运行 OpenLogReplicator 的主机。
3 OpenLogReplicator 正在监听的端口。

当连接器启动并开始流式传输时,它将连接到 OpenLogReplicator 进程的网络端点,与序列化进程协商连接,然后开始接收 redo 日志条目。

在接下来的几周内,在最终发布之前,我们将发布另一篇博客文章,更详细地介绍 OpenLogReplicator。在此期间,欢迎您尝试使用新的摄取方法,我们非常期待您的反馈。

由于此摄取方法是实验性的,存在一些已知限制,请参阅连接器 文档 以获取详细信息。

新的时区转换

社区经常提出的一个常见请求是能够使用除 UTC 之外的其他时区发出时间戳列。Debezium 一直支持此功能,方法是使用 CustomConverter 来更改时间戳列的默认发出方式,或者编写自己的单消息转换;但是,这些方法可能不适合所有人。

Debezium 2.4 现在附带了一个全新的时区转换器,可让您精细控制发出事件中的哪些时间戳列会从 UTC 转换为您管道所需的任何所需时区。要开始使用此新转换器,请将以下基本配置添加到您的连接器中:

{
  "transforms": "tz",
  "transforms.tz.type": "io.debezium.transforms.TimezoneConverter",
  "transforms.tz.converted.timezone": "America/New_York"
}

通过指定上述配置,所有以 UTC 发出的时间戳列都将从 UTC 转换为 America/New_York 时区。但是,您不仅限于更改所有时间戳字段的时区,还可以使用 include.fields 属性针对特定字段,如下所示:

{
  "transforms": "tz",
  "transforms.tz.type": "io.debezium.transforms.TimezoneConverter",
  "transforms.tz.converted.timezone": "America/New_York",
  "transforms.tz.include.fields": "source:customers:created_at,customers:updated_at"
}

在上面的示例中,第一个条目将转换源表名为 customerscreated_at 字段,而后者将转换主题名为 customersupdated_at 字段。此外,您还可以使用 exclude.fields 排除字段的转换,以将转换应用于除一组特定字段外的所有字段:

{
  "transforms": "tz",
  "transforms.tz.type": "io.debezium.transforms.TimezoneConverter",
  "transforms.tz.converted.timezone": "America/New_York",
  "transforms.tz.exclude.fields": "source:customers:updated_at"
}

在上面的示例中,所有时间戳字段都将转换为 America/New_York 时区,但当源表名为 customers 且字段为 updated_at 时除外。

您可以在 文档 中找到有关此新转换器的更多信息,我们非常期待您的反馈。

MongoDB 变更

Debezium 2.4.0.Beta2 还包含多项 MongoDB 连接器变更,让我们单独看一下。

重大变更

mongodb.hostsmongodb.members.autodiscover 配置属性已被移除,不再对 MongoDB 连接器行为产生任何影响。如果您之前依赖这些配置属性,则现在必须改用 MongoDB 连接字符串 配置属性(DBZ-6892)。

自定义身份验证

在某些特定环境(如 AWS)中,您需要使用 AWS IAM 基于角色的身份验证来连接到 MongoDB 集群;然而,这需要使用 AWS_CREDENTIAL_PROVIDER 设置属性。此提供程序负责创建会话并提供凭据。

为了在这些环境中实现更无缝的集成,已添加了一个新的配置属性 mongodb.authentication.class,允许您直接在连接器配置中定义凭据提供程序类。如果您需要使用此类提供程序配置,现在可以向连接器配置添加以下内容:

{
  "mongodb.authentication.class": "<fully-qualified-class-name-to-use>",
  "mongodb.user": "username",
  "mongodb.password": "password"
}

此外,如果身份验证需要使用除 admin 之外的另一个数据库,连接器配置还可以包含 mongodb.authsource 属性来控制应使用哪个身份验证数据库。

有关更多信息,请参阅 文档

可配置的聚合管道顺序

Debezium 2.4 现在提供了一种控制更改流管道聚合顺序的方法。这在聚合特定文档时可能至关重要,因为这些文档可能导致管道问题,例如大型文档。

默认情况下,连接器会先应用 MongoDB 内部管道过滤器,然后再应用用户构建的过滤器;然而,这可能导致大型文档进入管道,并且如果文档超过内部 16MB 限制,MongoDB 可能会抛出错误。在这些用例中,连接器现在可以配置为首先应用由 cursor.pipeline 定义的用户阶段来过滤掉这些用例,以避免管道因 16MB 限制而失败。

要实现此目的,只需将以下配置应用于连接器:

{
  "cursor.pipeline.order": "user_first",
  "cursor.pipeline": "<custom-pipeline-filters>"
}

有关更多详细信息,请参阅 文档

MongoDB 7 支持

MongoDB 7.0 已于上个月发布,Debezium 2.4 支持 MongoDB 7。

如果您打算将环境升级到 MongoDB 7,可以轻松完成,因为 Debezium 2.4+ 与新版本完全兼容。如果您遇到任何问题,请告知我们。

其他修复和改进

本次发布中有几处 bug 修复和稳定性改进,其中一些值得注意的有:

  • debezium.io 滚动到顶部标题中的文档内容部分。DBZ-5942

  • 仅发布增量而不是完整快照,以减小同步事件消息的大小 DBZ-6458

  • Postgres - 增量快照在主键中包含 enum 类型表的表上失败 DBZ-6481

  • 在快照 Schema 到历史 Topic 时未考虑 schema.history.internal.store.only.captured.databases.ddl 标志 DBZ-6712

  • ExtractNewDocumentState for MongoDB 在处理带有 REWRITE 的删除事件时忽略之前的文档状态 DBZ-6725

  • MongoDB 新文档状态提取:原始名称覆盖不起作用 DBZ-6773

  • 传播源列名出错 DBZ-6831

  • 支持截断大列 DBZ-6844

  • VStream grpc 通道在超过最大大小时始终重置 DBZ-6852

  • Kafka 偏移存储失败,出现 NPE DBZ-6853

  • JDBC 偏移存储 - 表名配置无效 DBZ-6855

  • JDBC sink 插入因分号在 Oracle 目标数据库中失败 DBZ-6857

  • Oracle test shouldContinueToUpdateOffsetsEvenWhenTableIsNotChanged 因 NPE 而失败 DBZ-6860

  • Tombstone 事件导致 JDBC 连接器出现 NPE DBZ-6862

  • Debezium-MySQL 未过滤 AWS RDS 内部事件 DBZ-6864

  • 在 ExecuteSnapshot 中执行 arrived 方法时避免获取 NPE DBZ-6865

  • errors.max.retries = 0 导致可检索的错误被忽略 DBZ-6866

  • 流式聚合管道因数据库过滤器和信号集合的组合而损坏 DBZ-6867

  • ChangeStream 聚合管道在应被排除的大型文档上失败 DBZ-6871

  • Oracle alter table drop constraint 在级联索引时失败 DBZ-6876

本次发布总共修复了 36 个问题。非常感谢所有为本次发布做出贡献的社区成员:Andy PicklerAnisha MohantyBreno MoreiraChris CranfordHarvey YueIndra ShuklaJakub CechacekJiri PechanecMario Fiore VitaleNancy XuNir LevyOndrej BabecThomas Thorntontison

展望与下一步?

Debezium 2.4 进展顺利,我们第二个 Beta2 预览版现已包含 OpenLogReplicator 支持。我们计划在接下来的几周内,在 2.4 最终版本发布过程中,专注于稳定性和识别任何回归问题。我们鼓励您试用 Debezium 2.4.0.Beta2。预计下周会发布 Beta3,以解决 OpenLogReplicator 的任何不足之处,并希望在月底发布最终版本。

别忘了 Debezium 社区活动,我曾在 邮件列表 上分享过。活动将于东部夏令时 9 月 21 日星期四上午 8:00(UTC 时间中午 12:00)举行,届时我们将讨论 Debezium 2.4 和未来。详情可在 Zulip 聊天线程 中找到,所以请务必参加,我们非常希望在那里见到您。

此外,如果您打算参加在加利福尼亚州圣何塞举行的 Current 2023(前身为 Kafka Summit),我将于周三下午与我的好朋友 Carles Arnal 一起进行一次关于 Debezium 和数据管道的演示。我的同事 Hans-Peter Grahsl 还有一个关于事件驱动设计的演示,您不容错过。如果您想见面聊聊 Debezium、您的经验,或者只是打个招呼,我都很乐意交流。请随时在 Zulip 上给我发消息(@Chris Cranford)或在 Twitter 上给我发通知(@crancran77)。

一如既往,如果您有任何想法或建议,也可以通过 邮件列表 或我们的 聊天 与我们联系。

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