MySQL 异常处理
配置和启动错误
以下几种情况会导致连接器启动失败，并在日志中报告错误或异常，然后停止运行：
connector 的配置无效。
connector 根据相关配置参数无法连接上 MySQL 服务器。
connector 在重启后尝试从故障点恢复，但MySQL 的 binlog 被清理无相应历史记录。
当发生这些情况时，报错信息会提供错误的细节并可能给出一些处理方法，当您排查问题后可尝试重启 connector 服务。
MySQL 变得不可用
如果 MySQL 服务变得不可用时，connector 会停止工作，需要当 MySQL 可用时重启 connector 服务。如果您的 MySQL 集群使用了 GTIDs 协议，可立即重启 connector 服务，它会连接集群中的另一台服务器，并根据读取的最后一次提交事务处开始继续读取 binlog 。
Kafka Connect 异常终止
如果 Kafka Connect 在分布式模式下运行，并且 Kafka Connect 进程正常停止。在关闭该进程之前，Kafka Connect 将该进程的连接器任务迁移到该组中的另一个 Kafka Connect 进程。 新的 connector tasks 能够准确地从先前任务停止的位置开始继续处理。 在连接器任务正常停止并在新进程上重新启动时，处理会有短暂的延迟。
Kafka Connect 崩溃
当 kafka connect 发生崩溃时，进程立即停止并且来不及提交最近的偏移量，在分布式部署环境下， kafka connect 会重启新的进程，但新的进程无法获得崩溃进程最新的偏移量，因此可能会存在重复提交相同事件的情况。
但每一个更改事件消息都包括了 connector 的元数据信息，您可以使用这些信息来判别重复提交的事件。
Kafka 服务不可用
当 kafka 服务变的不可用时，Debezium MySQL connector 会暂停直到它和 kafka 服务重新建立连接。
MySQL 清理 binlog 文件
如果 Debezium MySQL connector 停止时间过长，MySQL 服务器可能会清理 binlog 从而导致 connector 读取的最新位置被清理。当 connector 重启时如果发现原始读取位置被清理，会尝试重新初始化 snapshot，如果 snapshot 被禁止，则 connector 会异常终止。
PostgreSQL 异常处理
配置和启动错误
以下几种情况会导致连接器启动失败，并在日志中报告错误或异常，然后停止运行：
connector 的配置无效。
connector 根据相关配置参数无法连接上 PostgreSQL 服务器。
connector 在重启时尝试从故障发生时的记录偏移位重新继续读取，但 PostgreSQL 已经清理了相关的记录。
当发生这些情况时，报错信息会提供错误的细节并可能给出一些处理方法，当您排查问题后可尝试重启 connector 服务。
PostgreSQL 变得不可用
如果 PostgreSQL 服务变得不可用时，connector 会停止工作，需要当 PostgreSQL 可用时重启 connector 服务。
集群故障
发布版本 12 后，PostgreSQL 只允许在主服务器上设置逻辑复制槽。 这意味着您只能将 Debezium PostgreSQL connector 指向数据库集群的主服务器。 此外，复制槽本身不会传播到副本。 如果主服务器出现故障，则必须选举新的主服务器。
新的主服务器必须安装 logical decoding plug-in ，配置为供插件使用的复制槽，运行要捕获更改事件的数据库。 只有这样，您才能将连接器配置连接新服务器并重新启动 connector。
发生故障转移时有一些重要的警告，您应该暂停 Debezium 服务，并在验证有一个完整的复制槽并且没有丢失数据后重启服务。 故障转移后：
在允许应用程序写入新的主节点之前，必须有一个重新创建 Debezium 复制槽的进程，否则应用程序可能会错过更改事件。
您可能需要验证 Debezium 是否能够在旧主节点终止之前读取插槽中的所有更改。
恢复和验证是否有更改事件丢失的一种可靠方法是将故障主节点的备份恢复到故障前的位置。 虽然这在执行上可能很困难，但它允许您检查复制槽是否有任何未消费的更改。
Kafka Connect 异常终止
如果 Kafka Connect 在分布式模式下运行，并且 Kafka Connect 进程正常停止。在关闭该进程之前，Kafka Connect 将该进程的连接器任务迁移到该组中的另一个 Kafka Connect 进程。 新的 connector tasks 能够准确地从先前任务停止的位置开始继续处理。 在连接器任务正常停止并在新进程上重新启动时，处理会有短暂的延迟。
Kafka Connect 崩溃
如果 Kafka 连接器进程意外停止，它正在运行的任何连接器任务都会终止，并且不会记录它们最近处理的偏移量。当 Kafka Connect 在分布式模式下运行时，Kafka Connect 会在其他进程上重新启动这些连接器任务。但是PostgreSQL 连接器从早期进程记录的最后一个偏移量恢复。这意味着新的替换任务可能会生成一些在崩溃之前处理过的相同更改事件。重复事件的数量取决于偏移刷新周期和崩溃前的数据量变化。
在每个更改事件记录中，Debezium 连接器记录了事件起源相关的元数据信息，包括事件发生时 PostgreSQL 服务器时间、服务器事务的 ID 。消费者可以跟踪此信息，尤其是 LSN，以确定事件是否重复。
Kafka 服务不可用
当 kafka 服务变的不可用时，Debezium PostgreSQL connector 会暂停并重试连接，直到它和 kafka 服务重新建立连接。
Connector 停止服务了一段时间
如果连接器正常停止，则可以继续使用数据库。 任何更改都会记录在 PostgreSQL WAL 中。 当连接器重新启动时，它会从中断的地方继续提交更改。也就是说，它会为连接器停止时所做的所有数据库更改生成更改事件记录。
合理配置的 Kafka 集群能够以超大吞吐量处理数据。 Kafka Connect 是根据 Kafka 最佳实践编写的，如果有足够的资源，Kafka Connect 连接器也可以处理非常大量的数据库更改事件。 因此，在停止一段时间后，当 Debezium 连接器重新启动时，它很可能会赶上停止时数据库发生的更改。
