Percona ClusterSync 1.0.0 fügt automatisches Failover für MongoDB hinzu
Percona ClusterSync für MongoDB, das Tool, das Daten zwischen MongoDB-Clustern verschiebt, hat Version 1.0.0 mit einem eingebauten Aktiv-Standby-Hochverfügbarkeitsmodus erreicht. In einem Blogbeitrag vom 30. September 2026 erklärt Autor Adnan Supic, mit einem Hinweis des Herausgebers, der Inel Pandzic würdigt, dass ClusterSync bisher ein Single Point of Failure war: Wenn der Host, Container oder Pod, auf dem das Tool lief, abstürzte, stoppte die Replikation und ein Operator musste den Ausfall bemerken und den Prozess manuell wiederherstellen. Die neue Version ermöglicht es Operatoren, mehrere Instanzen gegen dieselben Quell- und Zielcluster laufen zu lassen, sodass eine Standby-Instanz automatisch übernimmt, wenn die aktive ausfällt.
Wie der neue Modus funktioniert, ist einfach. Sie können jetzt mehrere Percona-ClusterSync-Instanzen ausführen, die auf dieselben Quell- und Ziel-MongoDB-Cluster zeigen. Die Instanzen koordinieren sich über einen MongoDB-gestützten Lease, der auf dem Zielcluster in einer Datenbank namens percona_clustersync_mongodb gespeichert ist. Genau eine Instanz hält den Lease und ist AKTIV, das heißt, sie führt die Replikation aus. Die übrigen bleiben STANDBY und beobachten, ob der Lease abläuft. Es gibt keinen externen Koordinator; der bereits vorhandene Ziel-MongoDB-Cluster fungiert als Quelle der Wahrheit. Hochverfügbarkeit ist immer aktiv und erfordert keine Konfigurationsänderungen. Eine einzelne Instanz gewinnt den Lease einfach sofort und verhält sich genau wie zuvor. Wenn Sie Failover wünschen, starten Sie eine zweite oder dritte Instanz mit derselben Quelle und demselben Ziel, und die Bereitstellung ist abgeschlossen.
Drei Mechanismen machen das Failover sicher: Lease-basierte Wahl, Term-Fencing und checkpoint-basierte Wiederherstellung. Die Lease-Wahl vermeidet Split-Brain, weil der gesamte Koordinationszustand in der Datenbank percona_clustersync_mongodb auf dem Ziel liegt. Die Wahl ist ein einziger atomarer bedingter Schreibvorgang: Eine Instanz beansprucht den Lease nur, wenn der aktuelle abgelaufen ist, und der Ablauf wird anhand der Serveruhr bewertet. Zwei konkurrierende Standbys können nicht beide gewinnen, und Uhrenabweichungen zwischen ClusterSync-Hosts sind irrelevant, weil nur die Uhr von MongoDB zählt. Der Lease selbst ist ein kleines Dokument mit Feldern für Lease-ID, Term, Instanz-ID, Wahldatum und Ablaufzeit.
Term-basiertes Fencing verhindert einen klassischen Fehler in verteilten Systemen, der als Zombie-Write bekannt ist. Das Term-Feld ist ein monotoner Fencing-Token, der bei jeder Wahl und jedem Wechsel von AKTIV zu STANDBY erhöht wird und in jeden Checkpoint-Schreibvorgang gestempelt wird, den der AKTIVE in percona_clustersync_mongodb.checkpoints vornimmt. Wenn ein AKTIVER aufgrund einer Garbage-Collection-Pause, einer Netzwerkpartition oder eines Pods, der vor Ablauf des Leases beendet und neu gestartet wurde, ins Stocken gerät, läuft sein Lease ab, ein Standby wird befördert, und die alte Instanz könnte aufwachen und versuchen zu schreiben, als wäre nichts geschehen. Mit Term-Fencing trägt dieser Zombie-Aktive einen veralteten Term, das Ziel lehnt seine Checkpoint-Schreibvorgänge ab, die abgesetzte Instanz bemerkt dies und stuft sich selbst auf STANDBY herab. Der neue AKTIVE-Zustand wird nie beschädigt.
Bei der Beförderung setzt der neue AKTIVE die Replikation vom gespeicherten Checkpoint aus fort, demselben Crash-Recovery-Mechanismus, den ClusterSync schon immer verwendet hat, jetzt automatisch ausgelöst. Die Zeitvorgaben sind in dieser Version festgelegt: Die Lease-TTL beträgt 10 Sekunden, der AKTIVE erneuert alle 3 Sekunden, und jede Instanz sendet alle 3 Sekunden Heartbeats. In der Praxis wird ein hart beendeter AKTIVER innerhalb von ungefähr der Lease-TTL ersetzt. Eine Grenze ist zu beachten: Die Hochverfügbarkeit deckt die Change-Stream-Replikationsphase ab, aber der anfängliche Klon ist nicht fortsetzbar. Wenn der AKTIVE mitten im Klonen stirbt, wird trotzdem ein Standby befördert, erkennt den unterbrochenen Klon während der Wiederherstellung und schlägt sauber fehl mit einem expliziten Grund in den Protokollen und /status: initial clone interrupted by failover and is not resumable; start a new run to re-clone from scratch. Die Wiederherstellung ist ein einfaches /start auf dem neuen AKTIVEN, das die Synchronisierung von Grund auf neu startet. Das automatische Failover greift, sobald der Klon abgeschlossen ist und die kontinuierliche Replikation beginnt.
Der Betrieb einer HA-Bereitstellung ist so konzipiert, dass er explizit statt auf Vermutungen basiert. Jede Instanz pflegt ein Liveness-Dokument in percona_clustersync_mongodb.members auf dem Ziel, und API-Antworten enthalten einen Cluster-Umschlag, sodass ein Operator, der einen beliebigen Knoten abfragt, sehen kann, wer AKTIV ist, die erreichte Instanz, die Rolle und die vollständige Mitgliederliste mit Host, Port und Rolle jeder Live-Instanz. Wenn Sie einen Betriebsbefehl wie /start, /pause oder /finalize an einen STANDBY senden, antwortet dieser mit HTTP 409 und Fehler not_active, mit demselben Umschlag im Body, sodass Ihr Client sofort den AKTIVEN finden und es dort erneut versuchen kann. Der Umschlag erscheint nur, wenn mehr als ein Live-Mitglied beobachtet wird; eine einzelne Instanz liefert Antworten, die byte-identisch mit der API vor HA sind, sodass vorhandene Tools unverändert weiterarbeiten. Die Endpunkte /metrics und pprof werden in jeder Rolle bereitgestellt. Zur Bereinigung löschen zwei neue direkte Befehle den HA-Zustand auf dem Ziel, während kein Server läuft: pcsm reset members und pcsm reset lease.
Observability ist eingebaut. Jede Instanz exportiert HA-Metriken auf /metrics, in jeder Rolle: percona_clustersync_mongodb_ha_active ist ein Gauge, bei dem 1 AKTIV und 0 STANDBY bedeutet; percona_clustersync_mongodb_ha_term ist ein Gauge für den aktuellen Lease-Term; percona_clustersync_mongodb_ha_role_transitions_total ist ein Zähler für Rollenwechsel auf dieser Instanz. Mit diesen wenigen Metriken können Sie ein Dashboard erstellen, das die gesamte HA-Geschichte auf einen Blick erzählt: Eine Zustandszeitleiste von ha_active pro Instanz dient als Bereitstellungsliste und zeigt, wer AKTIV ist und seit wann, ha_term zeigt den aktuellen Fencing-Term, und die Rate von ha_role_transitions_total pro Instanz fungiert als Flatter-Detektor, wobei 0 stabil bedeutet und eine steigende Zahl auf Probleme hinweist. Das Projekt liefert genau ein solches Grafana-Dashboard-JSON in seinem Repository als Ausgangspunkt. Eine gesunde Bereitstellung mit drei Instanzen zeigt einen AKTIVEN, zwei STANDBY, Term 1 und keine Übergänge. Nachdem der AKTIVE beendet wurde, übernahm die Instanz auf Port 2243, der Lease-Term wurde auf 2 erhöht, und ihr Übergangszähler verzeichnete die Beförderung; der alte AKTIVE trat wieder als STANDBY bei.
Das Upgrade von der vorherigen Version erfordert einen manuellen Schritt: Der Replikationszustand von 0.9.0 ist nicht mit 1.0.0 kompatibel, daher sollten Operatoren pcsm reset gegen das Ziel ausführen, bevor sie die Replikation mit der neuen Version starten. Danach ist das Starten von mehr als einer Instanz so einfach wie das Ausführen desselben Befehls auf einem anderen Host: pcsm --source "mongodb://src-mongos:27017" --target "mongodb://tgt-mongos:27017". Überprüfen Sie /status auf einer der Instanzen und Sie sehen einen AKTIVEN und einen STANDBY. Beenden Sie den AKTIVEN und beobachten Sie, wie der Standby die Replikation innerhalb von Sekunden vom letzten Checkpoint aufnimmt. Percona lädt zu Fehlerberichten, Funktionsvorschlägen und Codebeiträgen ein und verweist für Erstsynchronisierungen auf die PCSM-Dokumentation.
Für Teams, die einen langlebigen Datenreplikationsauftrag betreiben, ist das Muster hier übertragbar. Speichern Sie den Leader-Wahlzustand im Zielsystem selbst, grenzen Sie alte Leader mit einer Versionsnummer ab, sodass veraltete Schreibvorgänge abgelehnt werden, und speichern Sie den Fortschritt in einem Checkpoint, damit ein Nachfolger fortfahren kann, ohne von Null neu zu starten. Observability-Metriken für Rolle, Term und Übergänge verwandeln ein Failover von einem zu entdeckenden Vorfall in ein überwachbares Ereignis. Organisationen, die diese Failover-Logik lieber nicht selbst betreiben möchten, können auf verwaltete Datenbankdienste wie AEU Data zurückgreifen, die Datenbanken mit Hochverfügbarkeit, automatisierten Backups und Überwachung betreiben, sodass ein Migrationstool ein zuverlässiges Ziel hat, gegen das es failovern kann.