7.8. Debezium PostgreSQL 连接器如何处理错误和问题


Debezium 是一个分布式系统,可捕获多个上游数据库中的所有更改,永远不会丢失或丢失事件。当系统正常运行或被仔细管理时,Debezium 会在每次更改事件记录时 完全 提供。

如果发生错误,系统将不会丢失任何事件。但是,当它从故障中恢复时,可能会重复一些更改事件。在这些异常情况下,Debebe (如 Kafka)提供 至少一次 更改事件。

详情包括在以下部分:

配置和启动错误

在以下情况下,当尝试启动时连接器会失败,在日志中报告错误/过期,并停止运行:

  • 连接器的配置无效。
  • 连接器无法使用指定的连接参数成功连接到 PostgreSQL。
  • 连接器从 PostgreSQL WAL 中的之前记录的位置(使用 LSN)重启,PostgreSQL 不再有该历史记录可用。

在这些情况下,错误消息包含有关此问题的详细信息,并可能会有推荐的临时解决方案。在更正配置或解决 PostgreSQL 问题后,重启连接器。

PostgreSQL 变得不可用

当连接器运行时,因为任意数量的原因,连接到的 PostgreSQL 服务器可能会不可用。如果发生这种情况,连接器会失败,并显示错误并停止。当服务器再次可用时,重启连接器。

外部 PostgreSQL 连接器以 PostgreSQL LSN 的形式存储最后处理的偏移量。连接器重启并连接到服务器实例后,连接器与服务器通信,以继续从该特定偏移流。只要 Debezium 复制插槽保持不变,这个偏移就可用。永远不会在主服务器上丢弃复制插槽,否则您将丢失数据。有关删除插槽的故障问题单的详情,请查看下一部分。

集群故障

自版本 12 起,PostgreSQL 只能在主服务器中进行 逻辑复制插槽。这意味着您可以将 Debezium PostgreSQL 连接器指向数据库集群的活动的主服务器。另外,复制插槽本身不会传播到副本。如果主服务器停机,则必须提升新的主服务器。

注意

一些管理的 PostgresSQL 服务(例如,AWS RDS 和 GCP CloudSQL)通过磁盘复制将复制实施到备用状态。这意味着复制插槽将复制,并在故障切换后仍然可用。

新的主插槽必须有一个复制插槽,该插槽被配置为由 pgoutput 插件和您要捕获更改的数据库使用。只有然后您只能将连接器指向新的服务器并重启连接器。

发生故障转移时需要考虑重要注意事项,您应该暂停 Debezium,直到您验证是否有没有丢失数据的不完整的复制插槽。故障转移后:

  • 在允许应用程序 写入新 主前,必须有一个重新创建 Debezium 复制插槽的进程。这很重要。如果没有此过程,您的应用程序可能会丢失更改事件。
  • 您可能需要验证 Debezium 是否能够 在旧主失败前读取插槽中的所有更改

恢复和验证是否存在任何更改的可靠方法是,在失败前马上将故障主到点的备份恢复。虽然这在管理上比较困难,但它允许您检查复制插槽是否有任何未恢复的更改。

Kafka Connect 进程安全停止

假设 Kafka Connect 在分布式模式下运行,并且 Kafka Connect 进程安全停止。在关闭此过程前,Kafka Connect 会将进程的连接器任务迁移到该组中的另一个 Kafka Connect 进程。新的连接器任务开始处理之前的任务停止的位置。处理会有一个短暂的延迟,同时连接器任务安全停止并在新进程中重启。

Kafka Connect 进程崩溃

如果 Kafka Connector 进程意外停止,则其运行的任何连接器任务会在不记录最近处理的偏移量的情况下终止。当 Kafka Connect 以分布式模式运行时,Kafka Connect 会在其他进程中重启这些连接器任务。但是,PostgreSQL 连接器会从之前进程 记录 的最后一个偏移中恢复。这意味着,新替换任务可能会生成一些在崩溃前处理的相同更改事件。重复事件的数量取决于偏移清除周期,以及数据在崩溃前更改的卷。

由于某些事件在从故障中恢复过程中可能会重复,因此消费者应始终预计一些重复事件。Debezium 更改是幂等的,因此一系列事件总会产生相同的状态。

在每个更改事件记录中,Debezium 连接器都会插入有关事件来源的特定于源的信息,包括 PostgreSQL 服务器事件的时间、服务器事务的 ID,以及写入事务更改的位置。消费者可以跟踪此信息,特别是 LSN,以确定事件是否是重复的。

Kafka 变得不可用

当连接器生成更改事件时,Kafka Connect 框架使用 Kafka producer API 在 Kafka 中记录这些事件。根据您在 Kafka Connect 配置中指定的频率定期,Kafka Connect 会记录在这些更改事件中显示的最新偏移。如果 Kafka 代理不可用,运行连接器的 Kafka Connect 进程会重复尝试重新连接到 Kafka 代理。换句话说,连接器任务会暂停,直到重新建立连接,此时的连接器会完全恢复它们停止的位置。

连接器在持续时间内停止

如果连接器安全停止,可以使用数据库。所有更改都会记录在 PostgreSQL WAL 中。当连接器重启时,它会恢复流更改。也就是说,它为连接器停止时所做的所有数据库更改生成更改事件记录。

正确配置的 Kafka 集群可以处理大量吞吐量。Kafka Connect 根据 Kafka 最佳实践编写,并有足够的资源处理大量数据库更改事件。因此,在停止一段时间后,当 Debezium 连接器重启时,可能会捕获到数据库更改,这在停止时发生。发生这种情况的速度取决于 Kafka 的功能和性能以及 PostgreSQL 中对数据所做的更改卷。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.