Cross-Cluster Replication für Disaster Recovery: Leader- und Follower-Indizes synchron halten

1. Was Cross-Cluster Replication ist und welches Problem sie löst

Cross-Cluster Replication repliziert einen Index kontinuierlich von einem Leader-Cluster auf einen oder mehrere Follower-Cluster, üblicherweise in einer räumlich getrennten Region oder einem anderen Rechenzentrum. Anders als eine gewöhnliche, clusterinterne Replika verläuft diese Replikation asynchron über die Cluster-Grenze hinweg und toleriert damit auch spürbare Netzwerklatenz zwischen den beteiligten Standorten.

Das gelöste Problem ist klar umrissen: Fällt der Leader-Cluster komplett aus, etwa durch einen Ausfall der zugrunde liegenden Cloud-Region, steht mit dem Follower-Cluster eine nahezu aktuelle Kopie der Daten an einem unabhängigen Standort zur Verfügung, auf die produktiv umgeschaltet werden kann, ohne auf die deutlich langsamere Wiederherstellung aus einem Snapshot warten zu müssen.

2. Leader- und Follower-Indizes: Architektur im Detail

Ein Follower-Index ist technisch ein spezieller, schreibgeschützter Index, der intern die Operationen des zugehörigen Leader-Index über dessen Transaction Log liest und in derselben Reihenfolge auf sich selbst anwendet. Dadurch bleibt die Dokumentenreihenfolge und damit auch die interne Konsistenz des Index erhalten, statt die Daten einfach als unabhängige Kopie neu zu indexieren.

Weil ein Follower-Index intern auf das Transaction Log des Leaders zugreift, unterstützt CCR ausschließlich Indizes mit Soft Deletes, was in aktuellen Elasticsearch-Versionen ohnehin der Standard ist. Der Follower-Index selbst nimmt keine direkten Schreiboperationen von Clients an, solange die Replikationsbeziehung aktiv ist, und dient in diesem Zustand ausschließlich als Lesekopie.

PUT eu_follower_produkte/_ccr/follow
{
  "remote_cluster": "eu_leader_cluster",
  "leader_index": "produkte",
  "max_read_request_operation_count": 5120,
  "max_outstanding_read_requests": 12
}

3. Einrichtung: Remote-Cluster und Replikationsverträge

Voraussetzung für CCR ist, ähnlich wie bei Cross-Cluster Search, eine Remote-Cluster-Verbindung vom Follower- zum Leader-Cluster. Über diese Verbindung liest der Follower-Cluster aktiv die Änderungen vom Leader, die Replikation wird also vom Follower initiiert und gesteuert, nicht vom Leader selbst aktiv an den Follower gesendet.

Für wiederkehrende Muster, etwa täglich rotierende Indizes eines zeitreihenbasierten Logging- oder Bestell-Index, lässt sich zusätzlich ein Auto-Follow-Pattern einrichten, das neu entstehende, zum Muster passende Leader-Indizes automatisch als Follower repliziert, ohne dass für jeden neuen Index manuell eine Replikationsbeziehung eingerichtet werden muss.

PUT _ccr/auto_follow/bestellungen-pattern
{
  "remote_cluster": "eu_leader_cluster",
  "leader_index_patterns": [ "bestellungen-*" ],
  "follow_index_pattern": "{{leader_index}}"
}

4. Wie nah an Echtzeit ist die Synchronisierung wirklich

CCR repliziert Änderungen in kurzen, kontinuierlichen Zyklen, typischerweise im Sekundenbereich, sobald neue Operationen im Transaction Log des Leader-Index verfügbar sind. Unter normaler Last liegt der sogenannte Replikationslag meist deutlich unter einer Minute, kann bei sehr hoher Schreiblast auf dem Leader oder bei eingeschränkter Netzwerkbandbreite zwischen den Regionen aber spürbar ansteigen.

Wichtig ist, dass CCR trotz der geringen Verzögerung kein synchrones Replikationsmodell ist: Ein Schreibvorgang auf dem Leader gilt bereits als erfolgreich, bevor er auf dem Follower angekommen ist. Im ungünstigsten Fall, etwa bei einem plötzlichen Totalausfall des Leaders exakt während einer laufenden Replikation, können dadurch die letzten, noch nicht replizierten Operationen verloren gehen.

5. Unterschied zu Snapshot-basierten Backups: RPO und RTO

Ein klassisches Snapshot-Backup wird periodisch erstellt, etwa stündlich oder täglich, und erzeugt damit einen potenziellen Datenverlust in Höhe des Intervalls zwischen zwei Snapshots, dem sogenannten Recovery Point Objective, kurz RPO. Bei einem Ausfall kurz vor dem nächsten geplanten Snapshot gehen entsprechend alle Änderungen seit dem letzten Snapshot verloren.

CCR reduziert den RPO auf den tatsächlichen Replikationslag von typischerweise wenigen Sekunden bis Minuten. Auch die Recovery Time Objective, also die Zeit bis zur Wiederherstellung eines funktionsfähigen Systems, fällt bei CCR deutlich geringer aus, weil der Follower-Cluster bereits vollständig läuft und lediglich von Follower- auf Leader-Betrieb umgestellt werden muss, statt einen Snapshot erst vollständig aus dem Repository zurückzuspielen.

6. Failover-Szenario: Umschalten auf den Follower-Cluster

Fällt der Leader-Cluster tatsächlich aus, wird der betroffene Follower-Index über den Pause- und anschließend den Unfollow-Befehl von seiner Replikationsbeziehung gelöst und in einen regulären, schreibbaren Index umgewandelt. Erst nach diesem Schritt kann der Follower-Cluster Schreibanfragen für den betroffenen Index überhaupt annehmen.

Anschließend muss die Anwendungsschicht, im Falle eines Magento-Shops also die Suchkonfiguration, auf die Endpunkte des ehemaligen Follower-Clusters umgestellt werden, etwa über eine DNS-Umschaltung oder eine geänderte Umgebungskonfiguration. Dieser gesamte Ablauf sollte vorab als konkretes, dokumentiertes Runbook vorliegen und regelmäßig getestet werden, damit er im echten Ernstfall nicht improvisiert werden muss.

# Follower-Index von der Replikation lösen und beschreibbar machen
curl -X POST "follower-cluster:9200/eu_follower_produkte/_ccr/pause_follow"
curl -X POST "follower-cluster:9200/eu_follower_produkte/_close"
curl -X POST "follower-cluster:9200/eu_follower_produkte/_ccr/unfollow"
curl -X POST "follower-cluster:9200/eu_follower_produkte/_open"

7. Failback: zurück zum ursprünglichen Leader

Ist der ursprüngliche Leader-Cluster wieder verfügbar, enthält er in der Regel veraltete Daten gegenüber dem inzwischen produktiv gewordenen ehemaligen Follower. Ein direktes erneutes Anlaufen des alten Leaders als Schreibziel würde zu widersprüchlichen, divergierenden Datenständen führen und ist deshalb keine sichere Option.

Der übliche Weg besteht darin, die Replikationsrichtung umzukehren: Der wiederhergestellte, ehemalige Leader wird als neuer Follower des inzwischen aktiven Clusters eingerichtet, holt die während des Ausfalls entstandenen Änderungen nach, und erst wenn beide Cluster wieder vollständig synchron sind, kann bei Bedarf ein geplantes Zurückschwenken auf den ursprünglichen Standort erfolgen.

8. Monitoring der Replikationslags und Auto-Follow-Patterns

Die Follow-Stats-API liefert pro Follower-Index detaillierte Kennzahlen, unter anderem die Anzahl der noch nicht verarbeiteten Operationen und den zeitlichen Abstand zwischen Leader- und Follower-Zustand. Ein kontinuierlich wachsender Lag ist ein frühes Warnsignal dafür, dass entweder die Netzwerkverbindung zwischen den Regionen ausgelastet ist oder der Follower-Cluster mit der Schreibrate des Leaders nicht mehr Schritt hält.

Zusätzlich sollte der Status aller Auto-Follow-Patterns regelmäßig geprüft werden, damit neu entstehende, zum Muster passende Indizes tatsächlich zuverlässig repliziert werden. Ein stillschweigend fehlgeschlagenes Auto-Follow-Pattern fällt im Normalbetrieb oft nicht auf, wird aber im Ernstfall zum Problem, wenn ausgerechnet der neueste, wichtigste Index nicht repliziert wurde.

# Replikationslag pro Follower-Index abfragen
curl "follower-cluster:9200/eu_follower_produkte/_ccr/stats?pretty"

# Status aller Auto-Follow-Patterns prüfen
curl "follower-cluster:9200/_ccr/auto_follow/stats?pretty"

9. Lizenz- und Kostenaspekte sowie Grenzen von CCR

Cross-Cluster Replication ist eine kommerzielle Funktion und erfordert mindestens eine Platinum-Lizenz beziehungsweise die entsprechende OpenSearch-Alternative, sofern eine reine Open-Source-Distribution ohne kommerziellen Support im Einsatz ist. Diese Lizenzkosten müssen den gewonnenen RPO- und RTO-Vorteilen gegenüber einer reinen Snapshot-Strategie gegenübergestellt werden.

Zusätzlich verdoppelt ein vollständig replizierter Follower-Cluster die benötigte Infrastruktur, da er dauerhaft im laufenden Betrieb mitläuft statt nur im Bedarfsfall aktiviert zu werden. Für kleinere Magento-Betriebe ohne strenge Verfügbarkeitsanforderungen bleibt deshalb häufig eine Kombination aus regelmäßigen Snapshots und einer dokumentierten, manuellen Wiederherstellungsprozedur die wirtschaftlichere Wahl.

10. Zusammenfassung

11. FAQ: Cross-Cluster Replication: Das Wichtigste auf einen Blick