Die Cross-Site-Replikation für Percona XtraDB Cluster löst das DR-Problem, ohne das Hauptcluster zu überlasten. Wir analysieren, wo Einschränkungen auftreten und wie sie in Kubernetes umgangen werden.
Das Problem zeigt sich nicht sofort — bis die Anforderungen an die Ausfallsicherheit über die Grenzen eines Rechenzentrums hinausgehen. Für Percona XtraDB Cluster (PXC) ist dies besonders sensibel, da der Cluster nahezu synchrone Replikation (virtually synchronous replication) verwendet. Das Hinzufügen eines entfernten DR-Standorts direkt in denselben Kontur erhöht die Latenzen (latency) und kann zu Flow-Control führen. In Kubernetes wird dies durch die Netzwerkabstraktion und dynamischen Endpunkte komplizierter. Infolgedessen stößt die Architektur auf einen Kompromiss: entweder Konsistenz und Synchronität oder geo-verteilte Stabilität.
Der gewählte Ansatz besteht darin, in zwei Cluster zu unterteilen: einen Haupt-Cluster (DC) und einen Backup-Cluster (DR), mit asynchroner Replikation (asynchronous replication) zwischen ihnen. Dies verringert den Druck auf den Hauptcluster und isoliert Netzwerkverzögerungen. Ein zentrales Werkzeug wird der Percona Operator for MySQL, der die Einrichtung der Cross-Site-Replikation über Kubernetes CR (custom resource) vereinfacht. Der Trade-off ist offensichtlich: Es entsteht ein Replikationsverzug, aber das System gewinnt an Stabilität und Managebarkeit. Zusätzlich wird der Mechanismus des automatischen Failovers der asynchronen Replikationsverbindung verwendet, der es DR ermöglicht, bei Ausfällen zwischen den DC-Knoten zu wechseln.
Die Implementierung beginnt mit dem DC-Cluster: drei PXC-Knoten, jeder mit einem externen Endpunkt (EXTERNAL IP), der für DR zugänglich ist. Im CR-Dokument werden Parameter für die interclusterliche Replikation aktiviert. Danach erfolgt ein Backup, das als Ausgangspunkt für DR verwendet wird. Auf der DR-Seite wird ein ähnlicher PXC-Cluster in einer separaten Kubernetes-Umgebung bereitgestellt. Nach der Wiederherstellung der Daten wird ein Replikationskanal mit Angabe aller EXTERNAL IP des Quellservers hinzugefügt.
In der Praxis tritt ein wichtiges Detail auf: die Authentifizierung. Bei der Verwendung von caching_sha2_password ist eine gesicherte Verbindung (SSL/TLS) erforderlich. Wenn diese nicht vorhanden ist, startet die Replikation nicht. Der Umweg besteht darin, GET_SOURCE_PUBLIC_KEY oder SOURCE_PUBLIC_KEY_PATH zu verwenden, was den Austausch von RSA-Schlüsseln beinhaltet. Danach kann sich DR korrekt mit DC verbinden. Innerhalb des DR-Clusters erfolgt die Synchronisation zwischen den Knoten bereits über Galera, das heißt, sie bleibt synchron.
Der Failover-Mechanismus funktioniert auf der Ebene der asynchronen Replikation. Wenn ein DC-Knoten nicht verfügbar ist, wechselt DR zu einem anderen, basierend auf Priorität (weight) und Reihenfolge der Knoten. Dies verringert das Risiko eines vollständigen Verbindungsverlusts. Es ist jedoch wichtig zu verstehen: Dies beseitigt nicht die Replikationsverzögerungen, sondern erhöht lediglich die Verfügbarkeit des Kanals.
Das Ergebnis ist eine funktionierende DR-Architektur für die Kubernetes-Umgebung mit verwalteter Komplexität. Der Hauptcluster leidet nicht unter entfernten Knoten, und DR erhält die Daten mit akzeptabler Verzögerung. Die Metriken in den Ausgangsdaten werden nicht angegeben, daher kann der lag oder throughput quantitativ nicht bewertet werden. Dennoch spiegelt das Schema den typischen industriellen Kompromiss wider: der Verzicht auf vollständige Synchronität zugunsten von Stabilität und Skalierbarkeit.
Besonders hervorzuheben ist die Wahl der Methode zur initialen Datenladung. Im Beispiel wird ein physisches Backup über XtraBackup verwendet, aber auch logische Varianten wie mysqldump oder mydumper sind zulässig. Dies beeinflusst die Wiederherstellungszeit und Konsistenz, ändert jedoch nicht das architektonische Prinzip.
Insgesamt sieht die Architektur wie eine evolutionäre Lösung aus: PXC bleibt innerhalb des DC synchron, während zwischen DC und DR eine asynchrone Schicht eingeführt wird. Dies verringert die Risiken einer Degradierung und bietet ein kontrollierbares Modell der Ausfallsicherheit für Kubernetes.