Vous avez raison concernant la procédure de restauration. La restauration est une activité ponctuelle.
La sauvegarde est une activité en cours d'exécution continue. Il n'y a pas de "J'ai fini de faire une sauvegarde" dans Kafka car les données Kafka sont un flux et il n'y a pas de fin. Bien sûr, vous pouvez supposer que si vous n'avez pas obtenu de nouvelles données pendant x secondes, vous avez "terminé", mais vous ne pouvez pas généraliser cela.
Jetez un oeil sur les #46 et #54 pour plus

56 : puis :

@itaventurier

La sauvegarde est une activité en cours d'exécution continue.

Cela suppose un flux continu de données 24x7x365, qui ne s'applique pas à tous les cas. Dans notre cas, le flux ne s'exécute que pendant X heures par jour, la sauvegarde n'a lieu qu'après cela et est en fait conçue comme une sauvegarde/un instantané quotidien des données.

Je pense qu'il devrait y avoir un moyen de détecter (en interne) qu'il n'y a pas eu de nouveaux messages pendant un temps X (intervalle éventuellement configurable) après quoi le processus de sauvegarde se terminerait normalement et mettrait ainsi fin au processus.

Une autre alternative (peut-être plus simple) consisterait à ne sauvegarder les messages que jusqu'à l'horodatage du démarrage de la sauvegarde. Je ne sais pas comment cela jouerait avec la sauvegarde des décalages. Peut-être d'abord sauvegarder les décalages, puis nous connaissons l'horodatage auquel nous avons sauvegardé les décalages et nous pouvons sauvegarder les messages jusqu'à cet horodatage.

Je vois ce que tu veux dire. Ouais, ce serait probablement bien d'avoir un moyen de faire des sauvegardes ponctuelles :pensant:
Cependant, ce n'est pas trivial car il n'y a pas de moyen facile de décider si un flux "est terminé".

Ce que vous pouvez faire dans votre cas :

• Laissez Kafka Backup s'exécuter en arrière-plan
• Kafka Backup écrit les données en continu en arrière-plan dans le système de fichiers
• kill -9 Kafka Backup dès qu'il est "fini", c'est à dire qu'il a fini d'écrire vos données. Cela devrait être rapidement après que vous ayez fini de produire des données
• déplacez les données de Kafka Backup vers votre nouvelle destination.

Je comprends qu'il s'agit d'un cas d'utilisation assez courant et je fournirai plus de documentation à ce sujet avec #2. Pour la v0.1, la documentation est le dernier gros problème, donc j'espère que cela devrait arriver bientôt ;)

je vois l'approche suivante

• #54 introduit un nouvel outil CLI autonome. L'outil CLI devrait prendre en charge cela.
• Nous ajoutons un nouveau drapeau --snapshot à l'outil CLI (ou ajoutons un nouvel outil appelé backup-snapshot.sh )

Comment détecter lorsqu'une sauvegarde est "terminée" (applicable uniquement si le drapeau --snapshot est défini) :

• Nous nous souvenons de l'heure à laquelle la sauvegarde est démarrée. Tous les enregistrements qui ont un horodatage plus récent sont ignorés lors de la sauvegarde
• Lorsqu'une partition ne produit pas de nouvelles données pendant un certain temps (par exemple 20s), nous supposons qu'il n'y a pas de nouvelles données

Qu'est-ce que tu penses?

Laissez Kafka Backup s'exécuter en arrière-plan

Le problème est exactement avec cette étape. Nous ne pouvons pas le laisser fonctionner en arrière-plan. Nous n'avons qu'une fenêtre spécifique lorsque nous pouvons faire l'instantané. Ce n'est pas à nous de décider quand nous pouvons faire une sauvegarde, il s'agit d'exigences réglementaires externes.

Nous nous souvenons de l'heure à laquelle la sauvegarde est démarrée. Tous les enregistrements qui ont un horodatage plus récent sont ignorés lors de la sauvegarde

Oui, c'est exactement ce que je voulais dire et je pense que cela supprimerait l'exigence de l'avoir en arrière-plan (et d'essayer de saisir le moment où tous les producteurs ont terminé).

Lorsqu'une partition ne produit pas de nouvelles données pendant un certain temps (par exemple 20s), nous supposons qu'il n'y a pas de nouvelles données

Je pense que cette option est mutuellement exclusive avec l'autre. Et je pense que le premier est meilleur car il donne un point de référence spécifique et ne repose pas sur la recherche d'une fenêtre lorsqu'il n'y a pas de messages.

En fait, je voulais écrire que c'est presque impossible avec Kafka, mais en écrivant j'ai eu une idée de solution :

Le kafka-consumer-groups renvoie la position actuelle du consommateur dans la partition, mais plus intéressant encore, il renvoie le décalage de fin actuel de chaque partition particulière. Cela signifie qu'il existe un moyen d'obtenir le dernier décalage pour une partition à un certain moment. Je n'ai actuellement aucune idée de comment cela est réalisé (besoin de vérifier le code).

Alors maintenant, il y a un chemin clair pour faire une sauvegarde à un moment (plus ou moins) :

1. Obtenez le décalage de fin de partition pour chaque partition à sauvegarder (quelque part ici : https://github.com/itadventurer/kafka-backup/blob/master/src/main/java/de/azapps/kafkabackup/sink /BackupSinkTask.java#L81 )
2. Consommer chaque partition
3. Dès qu'un enregistrement consommé a un décalage >= celui enregistré pour cette partition s'en souvient. Ignorez tous les enregistrements de la sauvegarde. (Voir https://github.com/itadventurer/kafka-backup/blob/master/src/main/java/de/azapps/kafkabackup/sink/BackupSinkTask.java#L63 )
4. Dès que toutes les partitions sont à jour, imprimez un message sur STDOUT
5. Utilisez le script wrapper pour détecter ce message et tuer kafka connect normalement. Similaire à la façon dont il est résolu lors de la restauration : https://github.com/itadventurer/kafka-backup/blob/master/bin/restore-standalone.sh#L232 -L252

Vous voyez que ce n'est vraiment pas si anodin.

Mon objectif actuel est d'améliorer la suite de tests et de stabiliser Kafka Backup pour une première version (voir https://github.com/itadventurer/kafka-backup/milestone/1). Je ne peux pas vous donner d'ETA pour cette fonctionnalité. Je serais plus qu'heureux d'examiner un PR pour cela (et je recherche également des mainteneurs supplémentaires ;) ) Je suis heureux de vous aider s'il y a des questions

Vous voyez que ce n'est vraiment pas si anodin.

Je suis plus du côté des opérations (comme la configuration, la surveillance des clusters Kafka, etc.). Alors je te fais confiance sur cette partie. Ce que je veux dire, c'est que de mon côté du travail, c'est quelque chose dont j'ai (et bien sûr beaucoup d'autres) besoin.

Je serais plus qu'heureux de revoir un PR pour cela (et je recherche également des mainteneurs supplémentaires ;) )

Je ne suis pas très doué avec Java/Scala pour être d'une grande aide ici. Si c'était Python, C/C++ ou à tout le moins Go, je pourrais aider :P

Salut!
au début - je suis heureux d'avoir trouvé votre solution, car je dois sauvegarder les données du sujet kafka
à la seconde - malheureusement, je ne pouvais rien écrire en Java/Scala, j'ai donc préparé un 'wrapper' pour vous 'backup-standalone.sh' avec python pour une solution de sauvegarde complète
https://gist.github.com/FloMko/7adf2e00cd80fe7cc88bb587cde999ce
Ce sera agréable de voir les mises à jour sur la prise en charge intégrée de la sauvegarde ponctuelle

Hey,
Merci pour votre travail! Comme solution de contournement temporaire, je pourrais imaginer d'ajouter ceci en tant que script supplémentaire à ce référentiel et de le remplacer plus tard par une solution intégrée. N'hésitez pas à l'ajouter en tant que Pull request :) (à ./bin/kafka-backup-point-in-time.py ou autre chose ;) )

Je suis sur le point de publier une implémentation complètement séparée écrite en Go qui ne repose pas sur l'API de connexion. Juste FYI. Nous l'utilisons déjà dans notre environnement de production.

@akamensky pourriez-vous partager votre solution ? dans la mesure où vous avez testé votre solution, tout ira bien

@FloMko, nous venons de le publier. Vous pouvez le trouver (ainsi qu'un binaire reconstruit) ici

Merci @WesselVS pour votre PR #99 ! Je viens de le fusionner au master. Fera une version avec cette amélioration et quelques autres correctifs bientôt.

@akamensky Cool ! Super de voir un peu plus de travail concernant Kafka Backups ;)