Я переношу соединители Kafka из кластера ECS в новый кластер, работающий в Kubernetes. Я успешно перенес исходные коннекторы Postgres, удалив их и заново создав в точных слотах репликации. Они продолжают писать в одни и те же темы в одном и том же кластере Kafka. А коннектор S3 в старом кластере продолжает читать из них и записывать записи в S3. Все работает как обычно.
Но теперь, чтобы переместить коннекторы приемника AWS s3, я сначала создал некритический коннектор s3 в новом кластере с тем же именем, что и в старом кластере. Я собирался подождать несколько минут, прежде чем удалить старый, чтобы не потерять данные. К моему удивлению, похоже (исходя из пользовательского интерфейса, предоставленного akhq.io), что один работник на этом новом коннекторе s3 присоединяется к существующей той же группе потребителей. Я полностью ожидал дублирования данных. На основе Сводный документ,
All Workers in the cluster use the same three internal topics to share connector configurations, offset data, and status updates. For this reason all distributed worker configurations in the same Connect cluster must have matching config.storage.topic, offset.storage.topic, and status.storage.topic properties.
Итак, из этого «того же кластера Connect» я подумал, что один и тот же идентификатор группы потребителей работает только в одном и том же кластере Connect. Но, судя по моим наблюдениям, у вас может быть несколько потребителей в разных кластерах, принадлежащих к одной и той же группе потребителей?
Исходя из этого, статья__consumer_offsets
используется потребителями, и, в отличие от других скрытых тем, связанных со «смещением», у него нет обозначения имени кластера.
Означает ли это, что я могу просто создать соединители приемника S3 в новом кластере Kubernetes, а затем удалить их в кластере ECS, не дублируя и не пропуская данные (при условии, что у них одинаковое имя -> одна и та же группа потребителей)? Я не уверен, что это правильный шаблон, который обычно используют люди.
Я не знаком с использованием кластера Kafka Connect, но я понимаю, что это кластер соединителей, не зависящий от кластера Kafka.
В этом случае, поскольку коннекторы используют один и тот же кластер Kafka, и вы просто перемещаете их с ECS на k8s, все должно работать так, как вы описываете. Информация о смещении потребителя, а информация о внутренних смещениях kafka connect хранится в кластере Kafka, поэтому на самом деле не имеет значения, где работают коннекторы, пока они подключаются к одному и тому же кластеру Kafka. Они должны перезапускаться с той же позиции или вести себя как дополнительные реплики одного и того же соединителя независимо от того, где они работают.
Спасибо! Ваш ответ имеет смысл. Перечитав некоторые документы и подумав об этом, я был достаточно уверен в том, чтобы перенести разъемы s3 именно таким образом! Поскольку коннектор приемника S3 получает свой идентификатор группы с именем «connect-<имя_коннектора>», а каждый коннектор в одном и том же кластере подключения должен иметь уникальное имя, случай наличия двух потребителей в одной группе обычно не возникает. В этом случае у нас есть два разных кластера, так что это уникальная ситуация. Но каждый коннектор — это просто группа рабочих задач, и именно они назначаются группам потребителей.