Debezium连接器任务处于未分配状态

本文介绍了Debezium连接器任务处于未分配状态的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

今天，%3中的一个节点不同步，已重新启动。 现在，当我检查连接器任务的状态时，它显示为未分配，即使连接器处于运行状态。 工作进程正在分布式模式下运行。

我尝试重新启动连接器，但它仍未分配，并且指向被带回群集中的同一工作节点。

以下是我的其中一个工作进程的属性文件，该文件在所有工作进程中都是相同的：

bootstrap.servers=something:9092 group.id=ffb-supply-kafka-connect key.converter=org.apache.kafka.connect.json.JsonConverter value.converter=org.apache.kafka.connect.json.JsonConverter key.converter.schemas.enable=false value.converter.schemas.enable=false offset.storage.topic=supply-kafka-connect-offsets config.storage.topic=supply-kafka-connect-configs status.storage.topic=supply-kafka-connect-status plugin.path=/var/lib/3p-kafka/connect-plugins/,/usr/share/3p-kafka/libs

连接器配置：

"connector.class": "io.debezium.connector.mysql.MySqlConnector", "snapshot.locking.mode": "minimal", "transforms.insertKey.fields": "external_shipment_id", "tasks.max": "1", "database.history.kafka.topic": "seller_oms_log_history_20220304200010", "transforms": "unwrap,insertKey,extractKey,alterKey", "transforms.extractKey.type": "org.apache.kafka.connect.transforms.ExtractField$Key", "include.schema.changes": "false", "table.whitelist": "seller_oms.shipment_log", "database.history.kafka.recovery.poll.interval.ms": "5000", "transforms.unwrap.drop.tombstones": "false", "database.history.skip.unparseable.ddl": "true", "transforms.unwrap.type": "io.debezium.transforms.ExtractNewRecordState", "value.converter": "org.apache.kafka.connect.json.JsonConverter", "database.whitelist": "seller_oms", "transforms.alterKey.type": "org.apache.kafka.connect.transforms.ReplaceField$Value", "key.converter": "org.apache.kafka.connect.json.JsonConverter", "database.user": "cdc_user", "transforms.extractKey.field": "external_shipment_id", "database.server.id": "20220304200010", "transforms.insertKey.type": "org.apache.kafka.connect.transforms.ValueToKey", "database.history.kafka.bootstrap.servers": "XX:9092,YY:9092,ZZ:9092", "transforms.alterKey.renames": "__source_ts_ms:updated_by_debezium_at", "database.server.name": "seller_oms_log", "heartbeat.interval.ms": "5000", "database.port": "3306", "key.converter.schemas.enable": "false", "database.hostname": "master.in", "database.password": "XXYYSS", "value.converter.schemas.enable": "false", "name": "shipment-log-connector-20220304200010", "errors.tolerance": "all", "transforms.unwrap.add.fields": "source.ts_ms", "snapshot.mode": "schema_only" 我创建了一个具有相同配置的新连接器，它在现有连接器出现故障的同一工作节点上工作得很好。 我不确定为什么老管道没有出现并进入运行状态进行任务。 当节点从群集中断开连接时，是否需要执行某些操作？重新连接后如何恢复该连接器？ 根据我的理解，如果一个工人停工，它应该自动将任务分配给另一个工人。

推荐答案

连接器恢复后是否继续？

运行连接分布式脚本后，它应该会重新平衡任务。

否则，将有/Restart API终结点

如果一个工人出现故障，它应该自动将任务分配给另一个工人

根据我的经验，当任务实际失败时，它们仍然失败，如果是临时失败，并且日志没有显示任何有用的东西，则需要点击重启终结点。但是，您的errors.tolerance设置可能有助于在一定程度上隔离问题