1. Symptômes observés

Un cluster Kafka à 3 nœuds a été déployé avec succès. Les courtiers sont en ligne et l'état du cluster apparaît sain. Les topics métier sont créés normalement et les messages peuvent être produits sans problème.

Cependant, les problèmes suivanst ont été constatés :

• Les consommateurs ne peuvent pas lire les messages
• La consommation est bloquée
• Les offsets ne peuvent pas être soumis
• Le topic interne __consumer_offsets présente un nombre de réplicas anormal, demeurant à 1 au lieu de 3

2. Cause racine

2.1 Historique de déploiement du cluster

Le cluster Kafka a été initialement déployé en configuration mononœud. Le topic interne __consumer_offsets, créé automatiquement lors de la première utilisation, utilise par défaut un facteur de réplication égal à 1.

Par la suite, le cluster a été étendu à 3 nœuds. Les paramètres de configuration suivants ont été modifiés pour ajuster les réplicas :

• offsets.topic.replication.factor=3
• default.replication.factor=3
• min.insync.replicas=2

2.2 Problème critique

Le topic interne __consumer_offsets est créé une seule fois automatiquement. Ses métadonnées sont stockées à deux emplacements :

1. Dans le répertoire des journaux Kafka (/opt/kafka/data)
2. Dans le cluster Zookeeper

La suppression du répertoire de données Kafka ne permet pas d'effacer les anciennes métadonnées présentes dans Zookeeper. lors du redémarrage du cluster, Kafka lit les anciens enregistrements Zookeeper et considère que le topic existe déjà, donc il ne le recrée pas.

Résultat final : le topic __consumer_offsets conserve un facteur de réplication de 1, ce qui entre en conflit avec le paramètre min.insync.replicas=2. Les consommateurs ne peuvent pas soumettre leurs offsets → la consommation est complètement défaillante.

3. Procédure de résolution

3.1 Vérification de la configuration

Les fichiers de configuraton des 3 serveurs Kafka ont été correctement modifiés :

• offsets.topic.replication.factor=3
• transaction.state.log.replication.factor=3
• transaction.state.log.min.isr=2
• default.replication.factor=3
• min.insync.replicas=2

Arrêt de tous les services Kafka

./bin/kafka-server-stop.sh

Suppression des données Kafka sur les 3 nœuds

cd /opt/kafka
rm -rf data/*

Connexion au client Zookeeper et suppression des métadonnées du ancien topic (étape critiuqe)

cd /opt/zookeeper/bin
./zkCli.sh -server 127.0.0.1:2181
#Exécution des commandes de suppression
deleteall /brokers/topics/__consumer_offsets
deleteall /config/topics/__consumer_offsets
quit

Démarrage du cluster Kafka

./bin/kafka-server-start.sh -daemon config/server.properties

Déclenchement de la reconstruction du topic (exécuter une consommation)

./bin/kafka-console-consumer.sh --bootstrap-server 192.168.100.50:9092 --topic test1 --from-beginning

Vérification du résultat de la correction

bin/kafka-topics.sh --describe --topic __consumer_offsets --bootstrap-server 192.168.100.50:9092

Démarrage d'un producer console vers le topic test1

./bin/kafka-console-producer.sh --broker-list 192.168.100.50:9092 --topic test1
>bonjour
>message_test
>

Démarrage d'un consumer console depuis le topic test1

./bin/kafka-console-consumer.sh --bootstrap-server 192.168.100.50:9092 --topic test1 --from-beginning
bonjour
message_test