Wie migriert man Daten zwischen verschiedenen Elasticsearch-Versionen und zwischen Clustern?

Neu bei Elasticsearch? Nehmen Sie an unserem Webinar „Erste Schritte mit Elasticsearch“ teil. Sie können jetzt auch eine kostenlose Cloud-Testversion starten oder Elastic auf Ihrem Rechner testen.

Wenn Sie einen Elasticsearch-Cluster aktualisieren möchten, ist es manchmal einfacher, einen neuen, separaten Cluster zu erstellen und die Daten vom alten Cluster in den neuen zu übertragen. Dies bietet den Nutzern den Vorteil, alle ihre Daten und Konfigurationen auf dem neuen Cluster mit allen ihren Anwendungen testen zu können, ohne das Risiko von Ausfallzeiten oder Datenverlust.

Die Nachteile dieses Ansatzes liegen darin, dass er eine gewisse Hardware-Duplizierung erfordert und Schwierigkeiten bei der reibungslosen Übertragung und Synchronisierung aller Daten verursachen kann.

Ein ähnliches Vorgehen kann auch erforderlich sein, wenn Sie Anwendungen von einem Rechenzentrum in ein anderes migrieren müssen.

In diesem Artikel werden wir drei Möglichkeiten zur Datenübertragung zwischen Elasticsearch-Clustern besprechen und detailliert beschreiben.

Wie migriert man Daten zwischen Elasticsearch-Clustern?

Es gibt 3 Möglichkeiten, Daten zwischen Elasticsearch-Clustern zu übertragen:

1. Neuindizierung von einem Remote-Cluster
2. Datenübertragung mithilfe von Snapshots
3. Datenübertragung mit Logstash

Die Verwendung von Snapshots ist in der Regel der schnellste und zuverlässigste Weg, Daten zu übertragen. Beachten Sie jedoch, dass Sie einen Snapshot nur auf einem Cluster derselben oder einer höheren Version wiederherstellen können und niemals mit einem Unterschied von mehr als einer Hauptversion. Das bedeutet, dass Sie einen 6.x-Snapshot auf einem 7.x-Cluster wiederherstellen können, aber nicht auf einem 8.x-Cluster.

Wenn Sie um mehr als eine Hauptversionsstufe aktualisieren müssen, müssen Sie entweder neu indizieren oder Logstash verwenden.

Schauen wir uns nun die drei Optionen zum Datentransfer zwischen Elasticsearch-Clustern genauer an.

1. Daten von einem Remote-Cluster neu indizieren

Bevor Sie mit der Neuindizierung beginnen, denken Sie daran, dass Sie für alle Indizes auf dem neuen Cluster geeignete Zuordnungen einrichten müssen. Dazu müssen Sie entweder die Indizes direkt mit den entsprechenden Zuordnungen erstellen oder Indexvorlagen verwenden.

Neuindizierung vom Remote-Server – Konfiguration erforderlich

Um die Daten von einem Remote-Server neu zu indizieren, sollten Sie die unten stehende Konfiguration zur elasticsearch.yml-Datei des Clusters hinzufügen, der die Daten empfängt. Bei Linux-Systemen befindet sich diese Datei üblicherweise hier: /etc/elasticsearch/elasticsearch.yml. Die hinzuzufügende Konfiguration lautet wie folgt:

Wenn Sie SSL verwenden, sollten Sie das CA-Zertifikat zu jedem Knoten hinzufügen und in der elasticsearch.yml-Datei für jeden Knoten die folgende Zeile in den Befehl einfügen:

Alternativ können Sie die unten stehende Zeile zu allen Elasticsearch-Knoten hinzufügen, um die SSL-Verifizierung zu deaktivieren. Diese Vorgehensweise ist jedoch weniger empfehlenswert, da sie nicht so sicher ist wie die vorherige Option:

Sie müssen diese Änderungen auf jedem Knoten vornehmen und einen rollierenden Neustart durchführen. Weitere Informationen dazu finden Sie in unserem Leitfaden.

Befehl zum Neuindizieren

Nachdem Sie den Remote-Host in der elasticsearch.yml-Datei definiert und gegebenenfalls die SSL-Zertifikate hinzugefügt haben, können Sie mit dem folgenden Befehl die Daten neu indizieren:

Dabei können Timeout-Fehler auftreten. Daher kann es sinnvoll sein, großzügige Timeout-Werte festzulegen, anstatt sich auf Standardwerte zu verlassen.

Schauen wir uns nun einige weitere häufige Fehler an, die beim Reindexieren von einem Remote-Server auftreten können.

Häufige Fehler beim Neuindizieren von Remote-Daten

1. Neuindizierung nicht auf der Whitelist.

Wenn dieser Fehler auftritt, bedeutet dies, dass Sie die Remote-Host-IP-Adresse oder den Knotennamen nicht wie oben beschrieben in Elasticsearch definiert oder vergessen haben, die Elasticsearch-Dienste neu zu starten.

Um das Problem für den Elasticsearch-Cluster zu beheben, müssen Sie den Remote-Host zu allen Elasticsearch-Knoten hinzufügen und die Elasticsearch-Dienste neu starten.

2. SSL-Handshake-Ausnahme

Dieser Fehler bedeutet, dass Sie vergessen haben, reindex.ssl.certificate_authorities wie oben beschrieben zu elasticsearch.yml hinzuzufügen. Um es hinzuzufügen:

2. Datenübertragung mithilfe von Snapshots

Denken Sie daran, wie oben erwähnt, dass Sie einen Snapshot nur auf einem Cluster mit gleicher oder höherer Version wiederherstellen können und niemals mit einem Unterschied von mehr als einer Hauptversion.

Wenn Sie um mehr als eine Hauptversionsstufe aktualisieren müssen, müssen Sie entweder neu indizieren oder Logstash verwenden.

Für die Datenübertragung mittels Snapshots sind folgende Schritte erforderlich:

Schritt 1. Hinzufügen des Repository-Plugins zum ersten Elasticsearch-Cluster – Um Daten zwischen Clustern mittels Snapshots zu übertragen, müssen Sie sicherstellen, dass das Repository sowohl vom neuen als auch vom alten Cluster aus zugänglich ist. Cloud-Speicheranbieter wie AWS, Google und Azure eignen sich im Allgemeinen ideal dafür. Um Schnappschüsse aufzunehmen, lesen Sie bitte unsere Anleitung und befolgen Sie die darin beschriebenen Schritte.

Schritt 2. Starten Sie den Elasticsearch-Dienst neu (rollierender Neustart).

Schritt 3. Erstellen Sie ein Repository für den ersten Elasticsearch-Cluster.

Schritt 4- Fügen Sie das Repository-Plugin zum zweiten Elasticsearch-Cluster hinzu.

Schritt 5- Repository als schreibgeschützt zum zweiten Elasticsearch-Cluster hinzufügen – Sie müssen ein Repository hinzufügen, indem Sie die gleichen Schritte wiederholen, die Sie zum Erstellen des ersten Elasticsearch-Clusters durchgeführt haben.

Wichtiger Hinweis: Wenn Sie den zweiten Elasticsearch-Cluster mit demselben AWS S3-Repository verbinden, sollten Sie das Repository als schreibgeschütztes Repository definieren:

Das ist wichtig, weil man das Risiko vermeiden möchte, dass Elasticsearch-Versionen innerhalb desselben Snapshot-Repositorys vermischt werden.

Schritt 6 – Wiederherstellen der Daten im zweiten Elasticsearch-Cluster – Nach Durchführung der oben genannten Schritte können Sie die Daten wiederherstellen und in den neuen Cluster übertragen. Bitte befolgen Sie die in diesem Artikel beschriebenen Schritte, um die Daten im neuen Cluster wiederherzustellen. 

3. Datenübertragung mit Logstash

Bevor Sie mit der Datenübertragung mit Logstash beginnen, denken Sie daran, dass Sie für alle Indizes auf dem neuen Cluster entsprechende Zuordnungen einrichten müssen. Dazu müssen Sie entweder die Indizes direkt erstellen oder Indexvorlagen verwenden.

Um Daten zwischen zwei Elasticsearch-Clustern zu übertragen, können Sie einen temporären Logstash-Server einrichten und diesen zum Übertragen Ihrer Daten zwischen den beiden Clustern verwenden. Für kleine Cluster sollte eine Instanz mit 2 GB RAM ausreichend sein. Für größere Cluster können Sie Vierkern-CPUs mit 8 GB RAM verwenden.

Eine Anleitung zur Installation von Logstash finden Sie hier.

Logstash-Konfiguration für die Datenübertragung von einem Cluster zu einem anderen

Eine grundlegende Konfiguration zum Kopieren eines einzelnen Index von Cluster A nach Cluster B sieht wie folgt aus:

Für eine sichere Elasticsearch-Suche können Sie die folgende Konfiguration verwenden:

Metadaten des Indexes

Die obigen Befehle schreiben in einen einzelnen benannten Index. Wenn Sie mehrere Indizes übertragen und die Indexnamen beibehalten möchten, müssen Sie die folgende Zeile zur Logstash-Ausgabe hinzufügen:

Wenn Sie die ursprüngliche ID des Dokuments beibehalten möchten, müssen Sie Folgendes hinzufügen:

Beachten Sie, dass das Festlegen der Dokumenten-ID die Datenübertragung erheblich verlangsamt. Behalten Sie die ursprüngliche ID daher nur bei, wenn dies unbedingt erforderlich ist.

Synchronisierung von Aktualisierungen

Alle oben beschriebenen Methoden benötigen eine relativ lange Zeit, und es kann vorkommen, dass Daten im ursprünglichen Cluster aktualisiert wurden, während Sie auf den Abschluss des Prozesses warten.

Es gibt verschiedene Strategien, um die Synchronisierung von Aktualisierungen zu ermöglichen, die während des Datenübertragungsprozesses aufgetreten sein könnten. Sie sollten sich mit diesen Fragen auseinandersetzen, bevor Sie mit diesem Prozess beginnen. Insbesondere sollten Sie Folgendes bedenken:

• Welche Methode verwenden Sie, um Daten zu identifizieren, die seit Beginn des Datenübertragungsprozesses aktualisiert/hinzugefügt wurden (z. B. ein Feld „last_update_time“ in den Daten)?
• Welche Methode können Sie verwenden, um das letzte Datenelement zu übertragen?
• Besteht die Gefahr, dass Datensätze doppelt angelegt werden? Normalerweise ist das der Fall, es sei denn, die von Ihnen verwendete Methode setzt die Dokument-ID während der Neuindizierung auf einen bekannten Wert.

Die verschiedenen Methoden zur Synchronisierung von Aktualisierungen werden im Folgenden beschrieben.

1. Einsatz von Warteschlangensystemen

Einige Systeme zur Datenerfassung und -aktualisierung verwenden Warteschlangen, die es ermöglichen, Datenänderungen, die in den letzten x Tagen empfangen wurden, „wiederzugeben“. Das könnte eine Möglichkeit bieten, alle vorgenommenen Änderungen zu synchronisieren.

2. Neuindizierung vom Remote-Server

Wiederholen Sie den Neuindexierungsprozess für alle Elemente, bei denen „last_update_time“ mehr als x Tage zurückliegt. Dies erreichen Sie, indem Sie der Reindexierungsanforderung einen „query“-Parameter hinzufügen.

3. Logstash

Im Logstash-Input können Sie eine Abfrage hinzufügen, um alle Elemente zu filtern, bei denen „last_update_time“ > x Tage zurückliegt. Allerdings führt dieser Prozess bei Daten, die keine Zeitreihendaten darstellen, zu Duplikaten, es sei denn, Sie haben die document_id festgelegt.

4. Momentaufnahmen

Es ist nicht möglich, nur einen Teil eines Index wiederherzustellen. Daher müssten Sie eine der anderen oben beschriebenen Datenübertragungsmethoden (oder ein Skript) verwenden, um alle Änderungen zu aktualisieren, die seit der Durchführung des Datenübertragungsprozesses vorgenommen wurden.

Die Wiederherstellung von Snapshots ist jedoch ein wesentlich schnellerer Prozess als die Neuindizierung/Logstash, sodass es möglich sein könnte, die Aktualisierungen für einen kurzen Zeitraum auszusetzen, während Snapshots übertragen werden, um das Problem von vornherein zu vermeiden.