#数据接入平台
数据接入、处理和分发平台
数据处理过程中，因格式问题处理失败的数据会怎么处理？
已采纳
数据处理过程如何知道处理的性能不足？
已采纳
数据处理的流程分为3个阶段，分别是：
其中，我们可以通过消费者的消息积压程度和消费速度的监控来查看阶段1消费能力的性能，以及目标 Topic 的生产速度的监控来查看阶段3生产能力的性能。
一般我们可以通过提高数据源 Topic 的分区数，从而提高任务可扩容的并发度上限，以达到提升任务整体性能的效果。... 展开详请
如何确认数据上报成功？
已采纳
当请求的云 API 接口返回 MessageId 字段时，即代表数据已上报成功。参见云 API 调用返回 云 API 返回结果。
上报数据，出现错误怎么处理？
已采纳
数据上报配额是多少，如何提升配额？
Kafka Connect 异常终止
已采纳
如果 Kafka Connect 在分布式模式下运行，并且 Kafka Connect 进程正常停止。在关闭该进程之前，Kafka Connect 将该进程的连接器任务迁移到该组中的另一个 Kafka Connect 进程。 新的 connector tasks 能够准确地从先前任务停止的位置开始继续处理。 在连接器任务正常停止并在新进程上重新启动时，处理会有短暂的延迟。... 展开详请
Kafka Connect 崩溃
已采纳
如果 Kafka 连接器进程意外停止，它正在运行的任何连接器任务都会终止，并且不会记录它们最近处理的偏移量。当 Kafka Connect 在分布式模式下运行时，Kafka Connect 会在其他进程上重新启动这些连接器任务。但是PostgreSQL 连接器从早期进程记录的最后一个偏移量恢复。这意味着新的替换任务可能会生成一些在崩溃之前处理过的相同更改事件。重复事件的数量取决于偏移刷新周期和崩溃前的数据量变化。n在每个更改事件记录中，Debezium 连接器记录了事件起源相关的元数据信息，包括事件发生时 PostgreSQL 服务器时间、服务器事务的 ID 。消费者可以跟踪此信息，尤其是 LSN，以确定事件是否重复。... 展开详请
Kafka 服务不可用
已采纳
Connector 停止服务了一段时间
已采纳
如果连接器正常停止，则可以继续使用数据库。 任何更改都会记录在 PostgreSQL WAL 中。 当连接器重新启动时，它会从中断的地方继续提交更改。也就是说，它会为连接器停止时所做的所有数据库更改生成更改事件记录。
合理配置的 Kafka 集群能够以超大吞吐量处理数据。 Kafka Connect 是根据 Kafka 最佳实践编写的，如果有足够的资源，Kafka Connect 连接器也可以处理非常大量的数据库更改事件。 因此，在停止一段时间后，当 Debezium 连接器重新启动时，它很可能会赶上停止时数据库发生的更改。 ... 展开详请
如何知道数据转储是否有堆积？
已采纳
CKafka 数据转储，即 Kafka 的数据流出转储到其他源中，常见的例如 kafka to es，kafka to clickhouse 等等。
同步服务会消费 CKafka 实例的消息，因此会生成对应的消费分组，可在控制台的 ConsumerGroup 管理页面查看，一般消费分组命名为 datahub-task-xxx。u000b同步服务消费到消息后，会写入转储目标的服务中，然后提交写入条数对应的 offset 位置。
因此判断转储是否堆积，可通过查看该消费分组的未消费的消息条数是否在持续增加来了解堆积情况。... 展开详请
数据有堆积如何处理？
已采纳
集群故障
已采纳
发布版本 12 后，PostgreSQL 只允许在主服务器上设置逻辑复制槽。 这意味着您只能将 Debezium PostgreSQL connector 指向数据库集群的主服务器。 此外，复制槽本身不会传播到副本。 如果主服务器出现故障，则必须选举新的主服务器。n新的主服务器必须安装 logical decoding plug-in ，配置为供插件使用的复制槽，运行要捕获更改事件的数据库。 只有这样，您才能将连接器配置连接新服务器并重新启动 connector。n发生故障转移时有一些重要的警告，您应该暂停 Debezium 服务，并在验证有一个完整的复制槽并且没有丢失数据后重启服务。 故障转移后：
恢复和验证是否有更改事件丢失的一种可靠方法是将故障主节点的备份恢复到故障前的位置。 虽然这在执行上可能很困难，但它允许您检查复制槽是否有任何未消费的更改。... 展开详请
配置和启动错误
已采纳
以下几种情况会导致连接器启动失败，并在日志中报告错误或异常，然后停止运行：
当发生这些情况时，报错信息会提供错误的细节并可能给出一些处理方法，当您排查问题后可尝试重启 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 服务不可用
已采纳
MySQL 清理 binlog 文件
已采纳
如果 Debezium MySQL connector 停止时间过长，MySQL 服务器可能会清理 binlog 从而导致 connector 读取的最新位置被清理。当 connector 重启时如果发现原始读取位置被清理，会尝试重新初始化 snapshot，如果 snapshot 被禁止，则 connector 会异常终止。... 展开详请
配置和启动错误
已采纳
以下几种情况会导致连接器启动失败，并在日志中报告错误或异常，然后停止运行：
当发生这些情况时，报错信息会提供错误的细节并可能给出一些处理方法，当您排查问题后可尝试重启 connector 服务。
PostgreSQL 变得不可用
已采纳
腾讯云开发者
