Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

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

Debezium 是一个分布式系统，用于捕获多个上游数据库中的所有更改，它不会丢失或丢失事件。当系统正常运行或谨慎管理时，Debezium 会 精确 发送每个更改事件记录。

如果出现错误，则系统不会丢失任何事件。但是，当它从错误中恢复时，可能会重复一些更改事件。在这些异常情况下，Debezium （如 Kafka）在发送更改事件时 至少 提供。

以下部分详情：

配置和启动错误

在以下情况下，连接器在尝试启动时失败，在日志中报告错误/exception，并停止运行：

  • 连接器的配置无效。
  • 连接器无法使用指定的连接参数成功连接到 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 最佳实践编写，并为 Kafka Connect 连接器有足够的资源处理大量数据库更改事件。因此，在停止一段时间后，当 Debezium 连接器重启时，可能会捕获在停止时进行的数据库更改。发生这种情况的时间取决于 Kafka 的功能和性能以及 PostgreSQL 中数据更改的卷。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat