Database operator für Open-Source-Datenbank ergänzt sichereres failover und verschlüsseltes PITR
Ein Database operator für die relationale Open-Source-Datenbank, die von vielen Webanwendungen genutzt wird, bietet jetzt ressourcenabhängige Abstimmung, Transaktionswiederherstellung bei einem asynchronen failover und verschlüsselte point-in-time recovery (PITR). Percona veröffentlichte am 29. Oktober 2026 Version 1.3.0 seines Open-Source-Operator für den Datenbankserver. Ein Kubernetes-Operator ist Software, die die Bereitstellung und den Betrieb einer Anwendung innerhalb von Kubernetes automatisiert. Laut Percona funktioniert dieser Operator auf jeder Kubernetes-Distribution, die den Standards der Cloud Native Computing Foundation entspricht.
Zwei geänderte Standardeinstellungen erfordern vor einem Upgrade Aufmerksamkeit. Leader election, der Prozess, der bei mehreren laufenden Controller-Instanzen einen Controller für Entscheidungen auswählt, ist jetzt automatisch aktiviert. Bei einer Entwicklungs- oder Debugging-Bereitstellung mit nur einem Controller lässt sich das bisherige Verhalten wiederherstellen, indem PSO_LEADER_ELECTION_ENABLED im operator Deployment auf false gesetzt wird. Die Version ermöglicht Administratoren außerdem, Einstellungen für Leader election über die Umgebungsvariablen PSO_LEADER_ELECTION_* anzupassen.
Die folgenreichere Änderung beim Upgrade betrifft asynchrone Cluster. asynchronous replication bestätigt eine festgeschriebene Transaktion, bevor eine sekundäre Datenbank sie notwendigerweise empfangen hat. Version 1.3.0 verlangt, dass Backups für diese Cluster aktiviert sind, und verweigert andernfalls den Abgleich, also das Anpassen des bereitgestellten Systems an seine deklarierte Konfiguration. Administratoren können stattdessen spec.unsafeFlags.asyncFailoverWithPossibleDataLoss auf true setzen. Dadurch wird die schnelle Heraufstufung wiederhergestellt, ohne zu versuchen, Transaktionen zu retten, die ausschließlich auf dem ausgefallenen Primary verblieben sind. Cluster mit Group Replication sind nicht betroffen.
Die automatische Abstimmung wird im Abschnitt automatic-configuration der Custom Resource des Clusters konfiguriert, also in dem Kubernetes-Dokument, das den gewünschten Zustand der Datenbank beschreibt. Für die Aktivierung sind sowohl CPU- als auch Arbeitsspeicherlimits erforderlich, da diese Limits die Grundlage für die Berechnung der Einstellungen des Datenbankservers bilden. Administratoren wählen mostlyReads, someWrites, equalReadsWrites oder heavyWrites als loadType aus und geben eine Datenbankserverversion im Format X.Y.Z an. Im Beispiel von Percona werden 8 GiB Arbeitsspeicher, vier CPUs, die Arbeitslast someWrites und die Datenbankserverversion 8.4.0 zugewiesen. Der Operator dimensioniert daraufhin den buffer pool, den wichtigsten In-Memory-Datencache des Datenbankservers, und zugehörige Einstellungen. Er berechnet sie neu, wenn sich die Ressourcen oder der Arbeitslasttyp ändern.
Einstellungen, deren Änderung der Datenbankserver während des Betriebs erlaubt, werden mit SET GLOBAL angewendet, sodass kein Neustart erforderlich ist. Statische Einstellungen erfordern weiterhin einen Neustart, weshalb der Operator die Pods nacheinander neu startet. Ein Pod ist eine Kubernetes-Einheit, die einen oder mehrere eng miteinander verbundene Container enthält. Diese Unterscheidung ist für den Betrieb wichtig: Die automatische Abstimmung verringert Konfigurationsabweichungen nach Ressourcenänderungen, macht aber nicht jede Datenbankeinstellung dynamisch anpassbar.
Der neue failover-Prozess behebt eine konkrete Schwachstelle von asynchronous replication. Wenn ein Primary ausfällt, nachdem er Transaktionen angenommen hat, aber bevor ein Replica die zugehörigen binary logs gelesen hat, die Datenbankänderungen in ihrer Reihenfolge aufzeichnen, können diese Transaktionen bei einer gewöhnlichen Heraufstufung verloren gehen. Version 1.3.0 erweitert den xtrabackup-sidecar auf jedem Datenbankserver-Pod. Ein sidecar ist ein unterstützender Container, der neben der Datenbank ausgeführt wird. Sein Endpoint POST /failover/stream auf Port 6450 kann binary logs als tar-Stream bereitstellen.
Während des failover prüft das Tool zunächst, ob der ausgefallene Primary wiederhergestellt wurde. Ist das nicht der Fall, stoppt es die Replikation, schreibt die vom Replica gehaltenen relay logs vollständig aus und liest Source_Log_File und Read_Source_Log_Pos, um den fehlenden Abschnitt zu bestimmen. Es ruft die fehlenden binary logs vom sidecar des ausgefallenen Primary ab, kürzt sie bis zur letzten vollständigen Transaktion und verbindet sie mit dem neuesten abgeschlossenen relay log. Anschließend läuft der SQL thread, der replizierte Änderungen auf die lokale Datenbank anwendet, bis alle geretteten Transaktionen verarbeitet wurden. Erst danach stuft der Orchestrator das ausgewählte Replica herauf.
Dieser Schutz hat eine wichtige Grenze. Der Datenbankserverprozess des bisherigen Primary kann ausgefallen sein, aber sein Pod und sein sidecar müssen erreichbar bleiben. Standardmäßig hat das failover-Tool ab seinem ersten Versuch eine Stunde Zeit, die Quelle zu erreichen und die fehlenden Änderungen anzuwenden. Der Timer wird nicht bei jedem erneuten Versuch zurückgesetzt. Nach Ablauf der Frist lässt die Richtlinie Abort den Cluster ohne Heraufstufung, während ForceWithPossibleDataLoss trotz der möglichen Lücke fortfährt. Die Backup-Anforderung soll sicherstellen, dass das unterstützende sidecar vorhanden ist. Teams sollten dennoch testen, ob es in ihren Ausfallszenarien erreichbar bleibt.
Die Version verschlüsselt außerdem binary logs, die für point-in-time recovery (PITR) an object storage gesendet werden. Dabei wird ein Backup wiederhergestellt und anschließend werden aufgezeichnete Änderungen bis zu einem ausgewählten Zeitpunkt erneut abgespielt. Verwendet wird envelope encryption: Jede Datei erhält einen eigenen data encryption key (DEK), und dieser Schlüssel wird durch einen key encryption key (KEK) geschützt. Der Operator liest den KEK aus einem Kubernetes Secret, anstatt das zentrale Schlüsselmaterial auf jedem Datenbankserver-Pod abzulegen. AES-256-CTR ist der standardmäßige symmetrische cipher. In der Verschlüsselungskonfiguration werden der cipher und die kekId angegeben, während keyringSecret das Secret und dessen keyring-Datei bezeichnet, deren Standardschlüssel keyring.json lautet.
Während einer Wiederherstellung liest das PITR-Tool die Metadaten der Datei, findet den angegebenen KEK, öffnet den dateispezifischen Schlüssel und streamt entschlüsselte Ereignisse über die Utility zum Replay von binary logs in die wiederhergestellte Datenbank. Ein fehlender keyring oder ein nicht vorhandener KEK führt zu einem ausdrücklichen Fehler, bevor eine unvollständige Wiederherstellung erzeugt wird. Das Beispiel von Percona kombiniert aktivierte Backups und PITR mit einem S3-Bucket, einem Secret für die Zugangsdaten, Endpoint, Region, AES-256-CTR, dem KEK-Eintrag alpha und einem separaten binlog-server-keyring-Secret.
Weitere Änderungen verlagern mehr Routinevorgänge in die Clusterspezifikation. Anwendungskonten können in spec.users zusammen mit Datenbanken, zulässigen Hosts, grants, optionalen Verweisen auf Passwort-Secrets und der Delegierung von grants deklariert werden. Der Backup-Speicher kann einer benutzerdefinierten Zertifizierungsstelle für privates MinIO oder andere S3-kompatible Endpoints vertrauen. TLS, die für Netzwerkverbindungen verwendete Verschlüsselung, kann einen clusterweit geltenden cert-manager ClusterIssuer verwenden. Bei der Zertifikatsrotation werden die alte und die neue Zertifizierungsstelle zusammengeführt, leaf certificates ohne Neustart des Datenbankservers neu geladen und die alte Zertifizierungsstelle entfernt, sobald ihre Verteilung bestätigt wurde.
Backups können jetzt mit Fristen versehen werden, damit ein zu lange laufender Job als fehlgeschlagen gemeldet wird, anstatt hängen zu bleiben. Operator-Logs bleiben über Controller-Neustarts hinweg erhalten, die Meldung des Replikationsrückstands zeigt, wie weit Replicas zurückliegen, und DigitalOcean Kubernetes wird offiziell unterstützt. Die Datenbankserverversion 9.7 wurde in die Matrix der unterstützten Versionen aufgenommen. Die Version umfasst außerdem asynchrone Cluster mit gerader Instanzzahl, bootstrap from backup, ClusterSet rejoin und einen Wechsel des Replikationstyps, der als Tech Preview gekennzeichnet ist. Das bedeutet, dass er zur Evaluierung verfügbar ist und nicht als fertige Produktionsfunktion gilt.