Почему распределенный соединитель Kafka умирает, когда блокируется узел, на котором я его создал?

Я запускаю коннектор Kafka в распределенном режиме в локальном «запускающем» контейнере Docker (отдельно от контейнера узла Kafka). Коннектор работает как положено, но когда я убиваю пусковой контейнер, коннектор перестает работать. Я ожидал, что он продолжит работать, поскольку считал, что он зарегистрирован и запущен на рабочем узле Kafka в другом контейнере. Моя установка более подробно описана ниже:

В настоящее время я запускаю все через контейнеры Docker локально. У меня есть:

  1. Узел Zookeeper (3.4.9)
  2. Узел Kafka (Apache, 0.10.1.0)
  3. Узел запуска.

узел запуска загружает соответствующую версию Kafka и распаковывает ее содержимое. Затем он создает источник коннектора, устанавливает путь к классам для включения необходимых JAR-файлов, а затем выполняет коннектор как таковой:

connect-distributed.sh config/connect-distributed.properties

Файл распределенных свойств устанавливает идентификатор группы, различные названия тем, схемы и преобразователи, а также серверы начальной загрузки (которые указывают на узел Kafka (2) выше).

Кажется, что эта команда выполняется правильно, и http-служба спокойного соединителя запускается успешно. Затем я могу отправить запрос POST на http://example:8083/connectors, предоставив конфигурацию для соединителя. задания. Команда завершается без ошибок, и соединитель успешно запускается. Я могу использовать тему в узле Kafka (2), и я вижу вывод, который указывает, что коннектор работает и отправляет данные.

Когда я убиваю узел запуска (3), я ожидаю, что соединитель продолжит работу, поскольку я зарегистрировал его в кластере Kafka, хотя и в кластере из одного. Соединитель не продолжает работать и, кажется, умирает вместе с узлом запуска. Разве теперь соединитель не должен управляться работником в кластере? Нужно ли менять способ запуска коннектора или я что-то недопонимаю?


person LaserJesus    schedule 06.12.2016    source источник


Ответы (1)


Коннекторы Kafka не работают на брокерах Kafka. Они выполняются в процессах «Kafka Connect Worker», что в вашем вопросе называется «узлом запуска». Эти процессы принимают запросы REST для соединителей и запускают соединители в рабочих процессах. Под капотом эти процессы просто взаимодействуют с брокерами Kafka через обычных производителей и потребителей. Kafka Connect предоставляет платформу поверх этих клиентов, чтобы упростить создание масштабируемых коннекторов, поэтому разработчикам коннекторов нужно сосредоточиться только на том, как извлекать или передавать данные в систему, для которой коннектор написан. Это означает, что обработка продолжается только в том случае, если хотя бы один рабочий процесс все еще жив.

Есть два типа рабочих процессов. В автономном режиме конфигурация коннектора нигде не сохраняется - вы обычно передаете ее через командную строку. Информация о смещении (т.е. какие данные вы уже скопировали) хранится в локальной файловой системе. Следовательно, в этом режиме вы можете только предположить, что возобновите работу с того места, где остановились, если перезапустите процесс на том же узле с доступом к той же файловой системе.

В распределенном режиме рабочие координируют распределение работы, и они совместно используют общее постоянное хранилище (в Kafka) для конфигураций соединителей, смещений и т. Д. Это означает, что если вы запустите один экземпляр и создадите соединитель, его завершение остановится. все работает. Однако, когда вы снова запустите экземпляр, он возобновит работу с того места, на котором остановился, без повторной отправки конфигурации соединителя, поскольку эта информация была сохранена в Kafka. Если вы запустите несколько экземпляров, они будут координировать свою работу для балансировки нагрузки между задачами, и если один экземпляр выйдет из строя (из-за сбоя, эластичного уменьшения количества запущенных экземпляров, сбоя питания и т. Д.), Оставшиеся экземпляры будут перераспределять работать автоматически.

Вы можете найти более подробную информацию о воркерах, различных типах и том, как отработка отказа работает в распределенном режиме в документации Confluent Kafka Connect

person Ewen Cheslack-Postava    schedule 11.12.2016
comment
Спасибо за ответ. Это означает, что часть конфигурации моего узла Kafka должна запускать соединитель, если я хочу, чтобы рабочий процесс выполнял хотя бы одну задачу соединителя на каждом узле в моем кластере Kafka? Второй вопрос: если по какой-то причине коннектор выходит из строя, мне нужно что-то, отслеживающее тему статуса коннектора, которое автоматически перезапустит его на нужном узле? - person LaserJesus; 11.12.2016
comment
Рабочие автоматически распределяют задачи, поэтому, пока вы запускаете хотя бы 1 коннектор и у вас достаточно задач, все рабочие будут активно обрабатывать данные. Для мониторинга да, вы можете отслеживать тему статуса и предпринимать соответствующие действия для перезапуска (если это имеет смысл; это может быть проблема с другой системой, которая не будет решена простым перезапуском задачи ). - person Ewen Cheslack-Postava; 12.12.2016
comment
В очередной раз благодарим за помощь. Итак, если у меня есть набор из трех узлов в моем кластере Kafka, я должен запустить соединитель на каждом узле, чтобы рабочий выполнял задачи для этого соединителя на каждом узле, гарантируя, что в случае отказа одного узла на рабочих другие узлы? Т.е. запуск коннектора на одном узле не приведет к автоматическому запуску коннекторов и их соответствующих рабочих на других узлах? - person LaserJesus; 12.12.2016