Pourquoi le connecteur distribué Kafka est-il en train de mourir lorsque le noeud sur lequel je l'ai créé est détruit?

Question

Je lance un connecteur Kafka en mode distribué dans un conteneur Docker local 'launch' (séparé du conteneur de noeud Kafka). Le connecteur fonctionne comme prévu, mais lorsque je tue le conteneur de lancement, le connecteur cesse de fonctionner. Je m'attendais à ce qu'il continue de fonctionner puisque je croyais qu'il était enregistré et fonctionnait sur un employé du nœud Kafka dans un autre conteneur. Mon installation plus en détail suit:

Actuellement, je cours tout à travers les conteneurs Docker localement. Je:

1. Un noeud Zookeeper (3.4.9)
2. Un noeud Kafka (Apache, 0.10.1.0)
3. Un nœud 'lance'.

Le noeud de lancement télécharge la version Kafka appropriée et décompresse son contenu. Il construit ensuite la source de connecteur, définit le chemin de classe pour inclure les fichiers JAR nécessaires, exécute alors le connecteur en tant que tel:

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

Le fichier de propriétés distribué définit l'ID de groupe, les différents noms de sujets, des schémas et des convertisseurs et aussi les serveurs bootstrap (qui pointent vers le noeud Kafka (2) ci-dessus).

Cette commande semble s'exécuter correctement, le service reposant du service http étant démarré correctement. Je peux ensuite émettre la demande POST à ​​http://example:8083/connectors, fournissant la configuration pour les tâches de connecteur. La commande se termine sans erreur et le connecteur est démarré avec succès. Je peux consommer à partir d'un sujet dans le noeud Kafka (2) et je vois la sortie qui indique que le connecteur fonctionne et envoie des données. Lorsque je tue le nœud de lancement (3), je m'attends à ce que le connecteur continue à fonctionner depuis que je l'ai enregistré avec le cluster Kafka, même s'il s'agit d'un cluster de 1. Le connecteur ne continue pas à fonctionner et semble mourir avec le noeud de lancement. Le connecteur n'est-il pas supposé être géré maintenant par un travailleur du cluster? Dois-je changer la façon dont je lance le connecteur ou suis-je en train de mal comprendre quelque chose?

Answer 1

Les connecteurs Kafka ne s'exécutent pas sur les courtiers Kafka. Ils sont exécutés dans les processus "Kafka Connect Worker", ce que votre question appelle un "nœud de lancement". Ces processus acceptent les demandes REST pour les connecteurs et exécutent les connecteurs dans les processus de travail. Sous le capot, ces processus interagissent simplement avec les courtiers Kafka via les producteurs et les consommateurs normaux. Kafka Connect fournit un cadre au-dessus de ces clients pour faciliter la création de connecteurs évolutifs, de sorte que les développeurs de connecteurs doivent uniquement se concentrer sur la manière d'extraire ou de pousser les données vers le système pour lequel le connecteur est écrit. Cela signifie que le traitement continue uniquement si au moins un processus de travail est toujours actif.

Il existe deux types de processus de travail. En mode autonome, la configuration du connecteur n'est conservée nulle part - vous la transmettez généralement via la ligne de commande. Les informations de décalage (c'est-à-dire les données que vous avez déjà copiées) sont conservées sur le système de fichiers local. Par conséquent, dans ce mode, vous pouvez supposer que vous reprendrez là où vous vous étiez arrêté si vous redémarrez le processus sur le même nœud avec l'accès au même système de fichiers.

En mode distribué, les travailleurs se coordonnent pour distribuer le travail et partagent un stockage commun et persistant (dans Kafka) pour les configs, les décalages, etc. Cela signifie que si vous démarrez une instance et créez un connecteur, arrêtez cette instance arrêtera tout travail.Toutefois, lorsque vous redémarrez une instance, elle reprend là où elle s'était arrêtée sans soumettre à nouveau la configuration du connecteur, car cette information a été conservée dans Kafka. Si vous démarrez plusieurs instances, elles coordonneront pour équilibrer les tâches entre elles, et si une instance échoue (en raison d'un crash, d'une réduction élastique du nombre d'instances en cours, d'une panne de courant, etc.), les instances restantes redistribueront fonctionne automatiquement.

Vous pouvez trouver plus de détails sur les travailleurs, les différents types et comment fonctionne le basculement en mode distribué in Confluent's Kafka Connect documentation