Kafka-backup: Compensation du consommateur

Salut Imran,

J'écris un article de blog sur la sauvegarde et la restauration des sujets Kafka dans un environnement Kubernetes avec un autre projet open source OpenEBS fournissant le stockage attaché au conteneur persistant sous-jacent.

La sauvegarde de Kafka à l'aide d'instantanés du système de fichiers n'est pas si simple. Voir https://github.com/azapps/kafka-backup/blob/master/docs/Comparing_Kafka_Backup_Solutions.md pour plus d'informations à ce sujet.

Pour l'instant, j'ai opté pour le connecteur S3 de Spredfast, mais mon ami Arash Kaffamanesh m'a indiqué votre travail. J'avais quelques questions.

Le connecteur S3 semble parfaitement bien si vous n'avez pas besoin de restaurer les décalages des consommateurs. J'ai plongé profondément dans le code source du connecteur S3 avant de le rejeter comme une solution à nos problèmes car il ne fournit pas cette fonctionnalité critique et il est difficile de l'étendre pour gérer ce cas.

Au moment de la restauration, comment faire savoir au consommateur par où commencer à consommer ?

Actuellement, le seul moyen est de simplement supprimer les segments qui ne doivent pas être restaurés et de recréer l'index. Il y aura bientôt plus d'informations sur la façon d'y parvenir. Si vous avez vraiment besoin de démarrer la restauration à partir d'un décalage très spécifique, veuillez ouvrir un problème. Cela ne devrait pas être difficile à mettre en œuvre.

Pouvez-vous s'il vous plaît partager des différences supplémentaires avec le connecteur de spredfast?

Encore une fois, le connecteur S3 n'est pas en mesure de synchroniser les décalages des consommateurs lors de la restauration. En fait, il n'y a tout simplement aucun moyen de le faire de manière fiable dans la version actuelle de Kafka. Grâce au travail de @ryannedolan sur Mirror Maker 2 , il y aura bientôt un moyen de le faire et kafka-backup utilise cette API. Heureusement, ce changement est même rétrocompatible et il y aura très bientôt une documentation sur l'utilisation kafka-backup cette façon.

De plus, le connecteur S3 prend uniquement en charge S3. Actuellement, kafka-backup ne prend en charge que la sauvegarde sur le système de fichiers, puis vous pouvez utiliser l'outil de votre choix pour le déplacer vers votre destination finale. Je prévois d'ajouter la prise en charge de plus de backends de stockage en cas de besoin.

En dehors de cela, les deux projets sont architecturalement très similaires (en fait, le connecteur S3 avec Mirror Maker 2 a inspiré kafka-backup )

mon environnement Kafka s'exécute dans Kubernetes. Idéalement, je veux un emplacement de stockage de sauvegarde/restauration en dehors de mon cluster afin de pouvoir le récupérer en cas de panne.

Autant que je sache, vous utilisez également Strimzi, nous avons la même sauvegarde. J'écrirai bientôt un article de blog expliquant comment effectuer une sauvegarde complète de Kafka et (n'oubliez pas cela !) Zookeeper sur Kubernetes et Strimzi.

emplacement de sauvegarde est déterminé par target.dir , il devient difficile de gérer un chemin sur un nœud si l'environnement est Kubernetes.

Montez simplement un volume persistant comme toujours. Utilisez un conteneur side-car pour le déplacer vers votre destination finale. Vous pouvez même garder le volume persistant relativement petit car vous pouvez supprimer les anciens segments et leur index dès qu'ils sont finalisés. (La documentation arrive)

Si vous attendez encore quelques jours, je publierai un article de blog d'introduction couvrant certains de vos sujets. Écrivez-moi un e-mail ou demandez à @arashkaffamanesh un brouillon :wink:

La contribution de @azapps est unique et géniale et je suppose que toute la communauté devrait aider à faire en sorte que la sauvegarde Kafka proposée et mise en œuvre par @azapps devienne un élément standardisé de l'écosystème Kafka !

Rien n'est parfait, mais cette implémentation par @azapps est géniale !

Pour mémoire : C'est parti : https://medium.com/@anatolyz/introducing -kafka-backup-9dc0677ea7ee