Kafka-backup: Verbraucherausgleich

Erstellt am 13. Juni 2019  ·  3Kommentare  ·  Quelle: itadventurer/kafka-backup

@azapps Zunächst einmal vielen Dank für dieses wunderbare Open-Source-Projekt.

Ich schreibe einen Blogbeitrag über die Sicherung und Wiederherstellung von Kafka-Themen in einer Kubernetes-Umgebung mit einem anderen Open-Source-Projekt OpenEBS, das den zugrunde liegenden persistenten Container-Attached-Storage bereitstellt.

Im Moment habe ich mich für den S3-Connector von Spredfast entschieden, aber mein Freund Arash Kaffamanesh hat mich auf Ihre Arbeit hingewiesen. Ich hatte ein paar Fragen.

Wie lasse ich den Verbraucher zum Zeitpunkt der Wiederherstellung wissen, wo er mit dem Konsum beginnen soll?
Können Sie bitte weitere Unterschiede zum Connector von spredfast mitteilen?

meine Kafka-Umgebung läuft in Kubernetes. Idealerweise möchte ich einen Sicherungs-/Wiederherstellungsspeicherort außerhalb meines Clusters, damit ich ihn im Falle eines Ausfalls wiederherstellen kann.

Sicherungsspeicherort durch target.dir bestimmt wird, wird es schwierig, einen Pfad auf einem Knoten zu verwalten, wenn die Umgebung Kubernetes ist.

Hilfreichster Kommentar

Hallo Imran,

Ich schreibe einen Blogbeitrag über die Sicherung und Wiederherstellung von Kafka-Themen in einer Kubernetes-Umgebung mit einem anderen Open-Source-Projekt OpenEBS, das den zugrunde liegenden persistenten Container-Attached-Storage bereitstellt.

Das Sichern von Kafka mithilfe von Dateisystem-Snapshots ist nicht so trivial. Weitere Informationen dazu finden Sie unter https://github.com/azapps/kafka-backup/blob/master/docs/Comparing_Kafka_Backup_Solutions.md .

Im Moment habe ich mich für den S3-Connector von Spredfast entschieden, aber mein Freund Arash Kaffamanesh hat mich auf Ihre Arbeit hingewiesen. Ich hatte ein paar Fragen.

Der S3-Anschluss scheint vollkommen in Ordnung zu sein, wenn Sie keine Consumer-Offsets wiederherstellen müssen. Ich bin tief in den Quellcode des S3-Konnektors eingetaucht, bevor ich ihn als Lösung für unsere Probleme abgetan habe, da er diese kritische Funktion nicht bietet und es schwierig ist, ihn zu erweitern, um diesen Fall zu bewältigen.

Wie lasse ich den Verbraucher zum Zeitpunkt der Wiederherstellung wissen, wo er mit dem Konsum beginnen soll?

Derzeit besteht die einzige Möglichkeit darin, einfach die Segmente zu löschen, die nicht wiederhergestellt werden sollen, und den Index neu zu erstellen. Es wird bald mehr Informationen darüber geben, wie man das erreichen kann. Wenn Sie die Wiederherstellung wirklich von einem ganz bestimmten Offset aus starten müssen, öffnen Sie bitte ein Problem. Das sollte nicht schwer umzusetzen sein.

Können Sie bitte weitere Unterschiede zum Connector von spredfast mitteilen?

Auch hier ist der S3-Anschluss nicht in der Lage, Verbraucher-Offsets während der Wiederherstellung zu synchronisieren. Tatsächlich gibt es in der aktuellen Kafka-Version einfach keine Möglichkeit, dies zuverlässig zu tun. Dank der Arbeit von @ryannedolan an Mirror Maker 2 wird es bald eine Möglichkeit geben, und kafka-backup verwendet diese API. Glücklicherweise ist diese Änderung sogar abwärtskompatibel und es wird sehr bald eine Dokumentation geben, wie man kafka-backup diese Weise verwendet.

Außerdem unterstützt S3 Connector nur S3. Derzeit unterstützt kafka-backup nur Backups auf das Dateisystem und dann können Sie jedes beliebige Tool verwenden, um es an Ihr endgültiges Ziel zu verschieben. Ich plane, bei Bedarf Unterstützung für weitere Speicher-Backends hinzuzufügen.

Abgesehen davon sind sich die beiden Projekte architektonisch sehr ähnlich (tatsächlich inspirierte der S3-Anschluss zusammen mit Mirror Maker 2 kafka-backup )

meine Kafka-Umgebung läuft in Kubernetes. Idealerweise möchte ich einen Sicherungs-/Wiederherstellungsspeicherort außerhalb meines Clusters, damit ich ihn im Falle eines Ausfalls wiederherstellen kann.

Soweit ich weiß, verwenden Sie auch Strimzi, wir haben das gleiche Backup. Ich werde bald einen Blogbeitrag schreiben, wie man ein vollständiges Backup von Kafka und (vergiss das nicht!) Zookeeper auf Kubernetes und Strimzi erstellt.

Sicherungsspeicherort durch target.dir bestimmt wird, wird es schwierig, einen Pfad auf einem Knoten zu verwalten, wenn die Umgebung Kubernetes ist.

Mounten Sie einfach wie immer ein persistentes Volume. Verwenden Sie einen Beiwagencontainer, um ihn an Ihren endgültigen Bestimmungsort zu transportieren. Sie können das persistente Volumen sogar relativ klein halten, da Sie alte Segmente und deren Index löschen können, sobald sie abgeschlossen sind. (Dokumentation folgt)

Wenn Sie noch ein paar Tage warten, werde ich einen einführenden Blogbeitrag veröffentlichen, der einige Ihrer Themen behandelt. Schreiben Sie mir eine E-Mail oder fragen Sie @arashkaffamanesh nach einem Entwurf :wink:

Alle 3 Kommentare

Hallo Imran,

Ich schreibe einen Blogbeitrag über die Sicherung und Wiederherstellung von Kafka-Themen in einer Kubernetes-Umgebung mit einem anderen Open-Source-Projekt OpenEBS, das den zugrunde liegenden persistenten Container-Attached-Storage bereitstellt.

Das Sichern von Kafka mithilfe von Dateisystem-Snapshots ist nicht so trivial. Weitere Informationen dazu finden Sie unter https://github.com/azapps/kafka-backup/blob/master/docs/Comparing_Kafka_Backup_Solutions.md .

Im Moment habe ich mich für den S3-Connector von Spredfast entschieden, aber mein Freund Arash Kaffamanesh hat mich auf Ihre Arbeit hingewiesen. Ich hatte ein paar Fragen.

Der S3-Anschluss scheint vollkommen in Ordnung zu sein, wenn Sie keine Consumer-Offsets wiederherstellen müssen. Ich bin tief in den Quellcode des S3-Konnektors eingetaucht, bevor ich ihn als Lösung für unsere Probleme abgetan habe, da er diese kritische Funktion nicht bietet und es schwierig ist, ihn zu erweitern, um diesen Fall zu bewältigen.

Wie lasse ich den Verbraucher zum Zeitpunkt der Wiederherstellung wissen, wo er mit dem Konsum beginnen soll?

Derzeit besteht die einzige Möglichkeit darin, einfach die Segmente zu löschen, die nicht wiederhergestellt werden sollen, und den Index neu zu erstellen. Es wird bald mehr Informationen darüber geben, wie man das erreichen kann. Wenn Sie die Wiederherstellung wirklich von einem ganz bestimmten Offset aus starten müssen, öffnen Sie bitte ein Problem. Das sollte nicht schwer umzusetzen sein.

Können Sie bitte weitere Unterschiede zum Connector von spredfast mitteilen?

Auch hier ist der S3-Anschluss nicht in der Lage, Verbraucher-Offsets während der Wiederherstellung zu synchronisieren. Tatsächlich gibt es in der aktuellen Kafka-Version einfach keine Möglichkeit, dies zuverlässig zu tun. Dank der Arbeit von @ryannedolan an Mirror Maker 2 wird es bald eine Möglichkeit geben, und kafka-backup verwendet diese API. Glücklicherweise ist diese Änderung sogar abwärtskompatibel und es wird sehr bald eine Dokumentation geben, wie man kafka-backup diese Weise verwendet.

Außerdem unterstützt S3 Connector nur S3. Derzeit unterstützt kafka-backup nur Backups auf das Dateisystem und dann können Sie jedes beliebige Tool verwenden, um es an Ihr endgültiges Ziel zu verschieben. Ich plane, bei Bedarf Unterstützung für weitere Speicher-Backends hinzuzufügen.

Abgesehen davon sind sich die beiden Projekte architektonisch sehr ähnlich (tatsächlich inspirierte der S3-Anschluss zusammen mit Mirror Maker 2 kafka-backup )

meine Kafka-Umgebung läuft in Kubernetes. Idealerweise möchte ich einen Sicherungs-/Wiederherstellungsspeicherort außerhalb meines Clusters, damit ich ihn im Falle eines Ausfalls wiederherstellen kann.

Soweit ich weiß, verwenden Sie auch Strimzi, wir haben das gleiche Backup. Ich werde bald einen Blogbeitrag schreiben, wie man ein vollständiges Backup von Kafka und (vergiss das nicht!) Zookeeper auf Kubernetes und Strimzi erstellt.

Sicherungsspeicherort durch target.dir bestimmt wird, wird es schwierig, einen Pfad auf einem Knoten zu verwalten, wenn die Umgebung Kubernetes ist.

Mounten Sie einfach wie immer ein persistentes Volume. Verwenden Sie einen Beiwagencontainer, um ihn an Ihren endgültigen Bestimmungsort zu transportieren. Sie können das persistente Volumen sogar relativ klein halten, da Sie alte Segmente und deren Index löschen können, sobald sie abgeschlossen sind. (Dokumentation folgt)

Wenn Sie noch ein paar Tage warten, werde ich einen einführenden Blogbeitrag veröffentlichen, der einige Ihrer Themen behandelt. Schreiben Sie mir eine E-Mail oder fragen Sie @arashkaffamanesh nach einem Entwurf :wink:

Der Beitrag von @azapps ist einzigartig und großartig, und ich denke, die gesamte Community sollte dazu beitragen, dass das vorgeschlagene und implementierte Kafka-Backup von @azapps zu einem standardisierten Teil des Kafka-Ökosystems wird!

Nichts ist perfekt, aber diese Umsetzung von @azapps ist genial!

Fürs Protokoll: Los geht's: https://medium.com/@anatolyz/introducing -kafka-backup-9dc0677ea7ee

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen