Reindex from Remote: Daten zwischen Clustern migrieren

1. Der klassische Weg: Snapshot, Restore und ihre Grenzen

Die traditionelle Methode, Daten zwischen zwei Elasticsearch-Clustern zu bewegen, führt über ein Snapshot-Repository: Der Quellcluster sichert seine Indizes in ein gemeinsam erreichbares Repository, etwa ein Shared-Filesystem oder einen Cloud-Storage-Bucket, und der Zielcluster stellt daraus die Indizes wieder her. Das funktioniert zuverlässig, setzt aber voraus, dass beide Cluster dasselbe Repository sehen können und dass die Snapshot-Formate zwischen den beteiligten Versionen kompatibel sind.

Gerade bei einem Versionssprung über mehrere Hauptversionen hinweg oder bei einem Wechsel des Hosting-Anbieters ist ein gemeinsam erreichbares Repository nicht immer praktikabel, etwa wenn Quell- und Zielcluster in getrennten Netzwerken oder bei unterschiedlichen Cloud-Anbietern laufen. Für solche Fälle bietet die Reindex-API mit ihrer Remote-Option eine Alternative, die ohne gemeinsames Speicherziel auskommt.

2. Die Reindex-API im lokalen Grundfall

Im einfachsten Fall kopiert POST _reindex Dokumente von einem Index in einen anderen Index desselben Clusters, gesteuert über ein JSON-Objekt mit den Feldern source und dest. Optional lässt sich über source.query eine Teilmenge der Dokumente auswählen, über script eine Transformation während der Kopie anwenden, und über dest.op_type festlegen, ob bestehende Dokumente im Ziel überschrieben oder übersprungen werden.

Dieser lokale Grundfall bildet die Basis für den Remote-Fall: Statt eines lokalen Quellindex verweist source.remote auf einen externen Cluster, dessen REST-Endpunkt erreichbar ist. Alle übrigen Optionen wie Query-Filterung, Skript-Transformation während der Kopie oder Slicing für Parallelisierung funktionieren identisch, unabhängig davon, ob die Quelle lokal oder remote liegt.

POST _reindex
{
  "source": { "index": "products_v1" },
  "dest": { "index": "products_v2" }
}

3. Wie Reindex from Remote technisch funktioniert

Bei einem Remote-Reindex fragt der Zielcluster den Quellcluster über dessen normale Such-API ab, paginiert intern über einen Scroll-Mechanismus, und schreibt jedes empfangene Dokument direkt über die Bulk-API in den eigenen Zielindex. Es entsteht zu keinem Zeitpunkt eine Zwischendatei oder ein Snapshot, die Daten fließen direkt von Cluster zu Cluster über HTTP oder HTTPS.

Diese direkte Kopplung erlaubt es, auch zwischen unterschiedlichen Hauptversionen zu migrieren, solange die Version des Quellclusters innerhalb des von der Zieldokumentation als unterstützt gekennzeichneten Bereichs liegt. Da der Zugriff über die reguläre REST-API läuft, gelten dabei dieselben Berechtigungsprüfungen wie für jeden anderen lesenden Zugriff auf den Quellcluster.

POST _reindex
{
  "source": {
    "remote": {
      "host": "https://old-cluster.example.com:9200",
      "username": "migration_reader",
      "password": "changeme"
    },
    "index": "products_v1"
  },
  "dest": { "index": "products_v2" }
}

4. Whitelisting: die Voraussetzung auf dem Zielcluster

Aus Sicherheitsgründen erlaubt Elasticsearch standardmäßig keinen Remote-Reindex gegen beliebige, unbekannte Hosts. Der Zielcluster muss die Quelle explizit über die statische Node-Einstellung reindex.remote.whitelist in der elasticsearch.yml freischalten, als Liste erlaubter Host-Port-Kombinationen, zum Beispiel [\"old-cluster.example.com:9200\"]. Diese Einstellung ist statisch, eine Änderung erfordert einen Neustart der betroffenen Knoten.

Wird ein Remote-Reindex gegen einen nicht freigeschalteten Host versucht, schlägt der Request mit einer eindeutigen Fehlermeldung fehl, bevor überhaupt eine Verbindung aufgebaut wird. In produktiven Umgebungen empfiehlt es sich, die Whitelist nur für den Zeitraum der Migration zu erweitern und den Eintrag danach wieder zu entfernen, statt dauerhaft eine offene Verbindungsmöglichkeit zu einem fremden Cluster zu hinterlassen.

5. Teilmigration mit Query-Filterung und Parallelisierung über Slicing

Bei sehr großen Indizes lohnt es sich selten, alles in einem einzigen, sequenziellen Reindex-Lauf zu übertragen. Über source.query lässt sich die Migration in sinnvolle Teilmengen aufteilen, etwa nach Zeitraum oder Kategorie, was auch eine schrittweise Validierung der übertragenen Daten erlaubt, bevor der komplette Bestand migriert wird.

Für die Parallelisierung innerhalb einer Teilmenge unterstützt die Reindex-API Slicing über den Parameter slices, entweder mit einer festen Anzahl oder mit dem Wert auto, der die Anzahl automatisch an die Shard-Zahl des Quellindex anpasst. Mehrere Slices laufen parallel und lesen jeweils nur einen Teil der Dokumente, was den Gesamtdurchsatz bei entsprechend leistungsfähiger Hardware deutlich erhöht.

POST _reindex?slices=auto
{
  "source": {
    "remote": { "host": "https://old-cluster.example.com:9200" },
    "index": "products_v1",
    "query": { "range": { "updated_at": { "gte": "2026-01-01" } } }
  },
  "dest": { "index": "products_v2" }
}

6. Praktischer Workflow bei einem Versionswechsel

Bei einem Upgrade über mehrere Hauptversionen hinweg, für das kein direkter Rolling-Upgrade-Pfad existiert, ist Remote-Reindex oft der pragmatischste Weg: Ein neuer Cluster in der Zielversion wird parallel zum bestehenden System aufgebaut, die Zielindizes werden mit dem korrekten Mapping und den gewünschten Einstellungen vorab angelegt, und anschließend zieht der neue Cluster die Daten per Remote-Reindex aus dem alten System.

Wichtig dabei ist, das Mapping des Zielindex vor dem Reindex-Lauf explizit zu definieren, statt sich auf dynamisches Mapping zu verlassen, da sich Feldtypen zwischen Versionen unterscheiden können und ein falsch erkannter Typ später kaum noch korrigierbar ist. Ebenso empfiehlt es sich, number_of_replicas während der Migration auf null zu setzen und erst danach wieder zu erhöhen, um den Schreibdurchsatz nicht unnötig zu bremsen.

7. Praktischer Workflow bei einem Cloud- oder Anbieterwechsel

Beim Wechsel von einer selbst gehosteten Umgebung in einen verwalteten Cloud-Dienst, oder zwischen zwei Cloud-Anbietern, gilt dasselbe Grundprinzip, ergänzt um Netzwerk- und Sicherheitsaspekte: Der Zielcluster muss den Quellcluster über das Netzwerk erreichen können, was je nach Infrastruktur ein VPN, eine explizite Firewall-Freigabe oder einen öffentlich erreichbaren, aber durch TLS und Authentifizierung abgesicherten Endpunkt erfordert.

Ein Wechsel weg von einer anderen Suchtechnologie wie Solr läuft nicht über die Reindex-API, da diese ausschließlich zwischen Elasticsearch-kompatiblen Clustern funktioniert. In einem solchen Fall übernimmt zunächst ein eigenes Ingestionsverfahren den initialen Import in einen ersten Elasticsearch-Cluster, und Reindex from Remote wird erst für spätere Konsolidierungen oder Umzüge zwischen mehreren Elasticsearch-Clustern relevant.

8. Sicherheit: Authentifizierung und Transportverschlüsselung

Läuft der Quellcluster mit aktivierter Sicherheit, müssen Zugangsdaten im source.remote-Block als Benutzername und Passwort mitgegeben werden, entweder direkt oder über einen API-Schlüssel. Diese Zugangsdaten werden bei jedem internen Request an den Quellcluster mitgesendet und sollten deshalb nur für die Dauer der Migration mit minimal notwendigen Leserechten vergeben werden, statt bestehende administrative Zugänge wiederzuverwenden.

Läuft die Quelle über HTTPS, prüft der Zielcluster standardmäßig das Zertifikat, was bei selbstsignierten Zertifikaten in Testumgebungen zu Verbindungsfehlern führen kann, falls die Zertifikatskette nicht im Truststore des Zielclusters hinterlegt ist. Für produktive Migrationen sollte die Zertifikatsprüfung aktiv bleiben und nicht pauschal deaktiviert werden, auch wenn das kurzfristig einfacher erscheint.

9. Monitoring und Troubleshooting während der Migration

Bei größeren Datenmengen empfiehlt sich wait_for_completion=false, wodurch die Reindex-API sofort eine Task-ID zurückgibt, statt die HTTP-Verbindung über die gesamte Laufzeit offen zu halten. Der Fortschritt lässt sich anschließend über GET _tasks/{task_id} abfragen, inklusive Angaben zu bereits verarbeiteten und noch verbleibenden Dokumenten, was eine realistische Restlaufzeitschätzung erlaubt.

Bricht eine Migration ab oder läuft unerwartet lange, lässt sich der zugehörige Task über POST _tasks/{task_id}/_cancel gezielt abbrechen, ohne den gesamten Cluster neu starten zu müssen. Häufige Fehlerursachen sind abgelaufene Verbindungstimeouts bei langsamen Netzwerkstrecken, die sich über socket_timeout und connect_timeout im source.remote-Block anpassen lassen, sowie Mapping-Konflikte, wenn das Zielschema nicht vorab korrekt definiert wurde.

# Fortschritt einer laufenden Remote-Migration abfragen
curl -s "https://target-cluster:9200/_tasks/oTUltX4IQMOUUVeiohTt8A:12345?pretty"

# Migration bei Bedarf gezielt abbrechen
curl -X POST "https://target-cluster:9200/_tasks/oTUltX4IQMOUUVeiohTt8A:12345/_cancel"

10. Zusammenfassung

11. FAQ: Reindex from Remote: Das Wichtigste auf einen Blick