Kafka-backup: Unterstützung von Zeitpunktsicherungen

Erstellt am 8. Apr. 2020  ·  13Kommentare  ·  Quelle: itadventurer/kafka-backup

Dies ist ein einmaliges Tool (bedeutet, dass es nach dem Backup nicht im Hintergrund ausgeführt werden muss), daher ist die Abhängigkeit vom Hintergrund-Daemon-Prozess lustig. Es besteht keine Notwendigkeit, kafka-connect als Daemon auszuführen.

enhancement help wanted

Alle 13 Kommentare

Bezüglich der Wiederherstellungsprozedur haben Sie Recht. Die Wiederherstellung ist eine einmalige Aktivität.
Das Backup ist eine kontinuierlich laufende Aktivität. In Kafka gibt es kein "Ich habe ein Backup abgeschlossen", da Kafka-Daten ein Stream sind und es kein Ende gibt. Sicher, Sie können davon ausgehen, dass Sie "fertig" sind, wenn Sie x Sekunden lang keine neuen Daten erhalten haben, aber Sie können das nicht verallgemeinern.
Schaut auf #46 und #54 für mehr

56: dann:

@itadventurer

Das Backup ist eine kontinuierlich laufende Aktivität.

Dies setzt einen kontinuierlichen Datenstrom 24x7x365 voraus, der nicht für alle Fälle gilt. In unserem Fall läuft der Stream nur X Stunden pro Tag, das Backup erfolgt erst danach und ist eigentlich als tägliches Backup/Snapshot von Daten gedacht.

Ich denke, es sollte eine Möglichkeit geben, (intern) zu erkennen, dass es für X Zeit (möglicherweise konfigurierbares Intervall) keine neuen Nachrichten gegeben hat, nach denen der Backup-Prozess ordnungsgemäß beendet und somit der Prozess beendet wird.

Eine andere (möglicherweise einfachere) Alternative dazu wäre, Nachrichten nur bis zum Zeitpunkt des Backup-Starts zu sichern. Ich bin mir nicht sicher, wie dies zusammen mit dem Sichern von Offsets funktionieren würde. Vielleicht zuerst Backup-Offsets, dann kennen wir den Zeitstempel, zu dem wir Offsets gesichert haben, und können Nachrichten bis zu diesem Zeitstempel sichern.

Ich verstehe dein Argument. Ja, wahrscheinlich wäre es schön, eine Möglichkeit zu haben, zu einem bestimmten Zeitpunkt Backups zu erstellen :thinking:
Dies ist jedoch nicht trivial, da es keine einfache Möglichkeit gibt, zu entscheiden, ob ein Stream "fertig" ist.

Was Sie in Ihrem Fall tun können:

  • Lassen Sie Kafka Backup im Hintergrund laufen
  • Kafka Backup schreibt kontinuierlich Daten im Hintergrund in das Dateisystem
  • kill -9 Kafka Backup sobald es "fertig" ist, dh es hat Ihre Daten fertig geschrieben. Dies sollte unmittelbar nach Abschluss der Datenproduktion erfolgen
  • Verschieben Sie die Daten von Kafka Backup an Ihr neues Ziel.

Ich verstehe, dass dies ein recht häufiger Anwendungsfall ist, und ich werde mit #2 mehr Dokumentation dazu bereitstellen. Für v0.1 ist die Dokumentation das letzte große Problem, also sollte dies hoffentlich bald passieren ;)


Ich sehe folgenden Ansatz

  • #54 führt ein neues eigenständiges CLI-Tool ein. Das CLI-Tool sollte dies unterstützen.
  • Wir fügen dem CLI-Tool ein neues Flag --snapshot (oder fügen ein neues Tool namens backup-snapshot.sh ).

So erkennen Sie, wann ein Backup "fertig" ist (gilt nur, wenn das Flag --snapshot gesetzt ist):

  • Wir erinnern uns an den Zeitpunkt, an dem das Backup gestartet wird. Alle Datensätze mit einem neueren Zeitstempel werden beim Backup ignoriert
  • Wenn eine Partition für einige Zeit (zB 20s) keine neuen Daten erzeugt, gehen wir davon aus, dass keine neuen Daten vorhanden sind

Was denken Sie?

Lassen Sie Kafka Backup im Hintergrund laufen

Das Problem liegt genau bei diesem Schritt. Wir können es nicht im Hintergrund laufen lassen. Wir haben nur ein bestimmtes Fenster, wenn wir den Snapshot machen können. Es liegt nicht an uns zu entscheiden, wann wir Backups durchführen können, es handelt sich um externe behördliche Anforderungen.

Wir erinnern uns an den Zeitpunkt, an dem das Backup gestartet wird. Alle Datensätze mit einem neueren Zeitstempel werden beim Backup ignoriert

Ja, genau das meinte ich und ich denke, dies würde die Notwendigkeit beseitigen, es im Hintergrund laufen zu lassen (und zu versuchen, den Moment einzufangen, in dem alle Produzenten fertig sind).

Wenn eine Partition für einige Zeit (zB 20s) keine neuen Daten erzeugt, gehen wir davon aus, dass keine neuen Daten vorhanden sind

Ich denke, diese Option schließt sich mit der anderen gegenseitig aus. Und ich denke, der erste ist besser, da er einen bestimmten Referenzpunkt liefert und nicht darauf angewiesen ist, ein Fenster zu finden, wenn keine Nachrichten vorhanden sind.

Eigentlich wollte ich schreiben, dass das bei Kafka fast unmöglich ist, aber beim Schreiben kam mir eine Idee für eine Lösung:

kafka-consumer-groups gibt die aktuelle Position des Consumers in der Partition zurück, aber noch interessanter gibt es den aktuellen End-Offset jeder einzelnen Partition zurück. Dies bedeutet, dass es eine Möglichkeit gibt, den neuesten Offset für eine Partition zu einem bestimmten Zeitpunkt abzurufen. Ich habe derzeit keine Ahnung, wie dies erreicht wird (muss den Code überprüfen).

Jetzt gibt es also einen klaren Weg, wie man ein (mehr oder weniger) zeitpunktbezogenes Backup erstellt:

  1. Holen Sie sich den End-of-Partition-Offset für jede zu sichernde Partition (Irgendwo hier: https://github.com/itadventurer/kafka-backup/blob/master/src/main/java/de/azapps/kafkabackup/sink /BackupSinkTask.java#L81 )
  2. Verbrauchen Sie jede Partition
  3. Sobald ein verbrauchter Datensatz einen Offset von >= hat, merkt sich der gespeicherte Datensatz für diese Partition dies. Ignorieren Sie alle Datensätze in der Sicherung. (Siehe https://github.com/itadventurer/kafka-backup/blob/master/src/main/java/de/azapps/kafkabackup/sink/BackupSinkTask.java#L63 )
  4. Sobald alle Partitionen auf dem neuesten Stand sind, drucken Sie eine Nachricht an STDOUT
  5. Verwenden Sie das Wrapper-Skript, um diese Nachricht zu erkennen und kafka connect ordnungsgemäß zu beenden. Ähnlich wie es während der Wiederherstellung gelöst wird: https://github.com/itadventurer/kafka-backup/blob/master/bin/restore-standalone.sh#L232 -L252

Du siehst, das ist wirklich nicht trivial.

Mein derzeitiger Fokus liegt darauf, die Testsuite zu verbessern und Kafka Backup für eine erste Version zu stabilisieren (siehe https://github.com/itadventurer/kafka-backup/milestone/1). Ich kann Ihnen keine ETA für diese Funktion geben. Gerne prüfe ich dazu eine PR (und suche auch noch weitere Betreuer ;) ) Bei Fragen stehe ich gerne zur Verfügung

Du siehst, das ist wirklich nicht trivial.

Ich beschäftige mich eher mit der Betriebsseite (wie Einrichtung, Überwachung von Kafka-Clustern usw.). Daher vertraue ich Ihnen in dieser Hinsicht. Mein Punkt ist, dass dies von meiner Seite aus etwas ist, was ich (und ziemlich sicher viele andere) brauchen.

Gerne prüfe ich dazu eine PR (und suche auch noch weitere Betreuer ;) )

Ich kenne mich mit Java/Scala nicht so gut aus, um hier eine große Hilfe zu sein. Wenn es Python, C/C++ oder zumindest Go wäre, könnte ich helfen :P

Hallo!
zunächst bin ich froh, deine Lösung gefunden zu haben, da ich Kafka-Themendaten sichern muss
an zweiter Stelle - leider konnte ich nichts in Java/Scala schreiben, also habe ich 'wrapper' für Sie vorbereitet 'backup-standalone.sh' mit Python für eine vollständige Backup-Lösung
https://gist.github.com/FloMko/7adf2e00cd80fe7cc88bb587cde999ce
Es wäre schön, alle Updates über die integrierte Unterstützung für zeitpunktbezogene Sicherungen zu sehen

Hey,
Danke für deine Arbeit! Als vorübergehenden Workaround könnte ich mir vorstellen, dies als zusätzliches Skript zu diesem Repository hinzuzufügen und später durch eine integrierte Lösung zu ersetzen. Fühlen Sie sich frei, dies als Pull-Request hinzuzufügen :) (an ./bin/kafka-backup-point-in-time.py oder etwas anderes ;) )

Ich bin dabei, eine komplett separate, in Go geschriebene Implementierung zu veröffentlichen, die nicht auf die Connect-API angewiesen ist. Nur zu deiner Information. Wir verwenden es bereits in unserer Produktionsumgebung.

@akamensky könnten Sie Ihre Lösung teilen? Soweit du deine Lösung getestet hast, ist es in Ordnung

@FloMko wir haben es gerade veröffentlicht. Sie finden es (sowie eine neu erstellte Binärdatei) hier

Danke @WesselVS für deine PR #99! Ich habe es gerade mit Master zusammengeführt. Wird demnächst ein Release mit dieser Verbesserung und einigen anderen Fixes veröffentlichen.

@akamensky Cool! Schön, dass wir noch mehr Arbeit in Bezug auf Kafka Backups sehen ;)

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen