Support für Open-Source-Datenbankcluster endet und erzwingt Entscheidungen zur Wartung
Der Galera-Cluster der relationalen Open-Source-Datenbank hat laut Percona das Ende seines bisherigen Entwicklungs- und Wartungswegs erreicht. Damit rücken Unterstützung bei Störungen und künftige Fehlerbehebungen ins Zentrum einer betrieblichen Entscheidung für Datenbankteams. In einem Artikel vom 8. Oktober 2026 berichtet Valeria Bogatyreva, dass der Datenbankanbieter, der Codership im Mai 2025 übernommen hat, den 30. September 2026 als Supportende für alle aktuellen Versionen des Galera-Clusters dieser Datenbank festgelegt hat. Nach dieser Regelung enden Entwicklung, Wartung und die Veröffentlichung von Binärpaketen, also direkt installierbaren Softwarepaketen.
Ein Cluster ist eine Gruppe zusammenarbeitender Datenbankserver, die als Knoten bezeichnet werden. Galera stellt die Replikation bereit, also den Mechanismus, der ihre Daten aufeinander abstimmt. Der Stichtag selbst ändert nichts am Betrieb eines installierten Clusters: Er sollte sich am 1. Oktober genauso verhalten wie am Vortag. Was sich ändert, ist der Weg zur Hinzuziehung von Fachleuten und zu einer späteren Softwarekorrektur. Diese Unterscheidung ist wichtig, weil eine Datenbank weiterlaufen kann, obwohl die Vorkehrungen für die Behebung ihrer nächsten schwierigen Störung nicht mehr bestehen.
Nicht allein die Replikation, sondern auch die Diagnose kann die Dauer eines Ausfalls bestimmen. Bogatyreva nennt Vorfälle, die dem Codership-Team zugeschrieben werden und bei denen sich Abfragen aufstauten, ohne dass hilfreiche Fehlermeldungen in den Protokollen erschienen – den Aufzeichnungen, die Software über ihre Aktivitäten hinterlässt. Ein Ausfall dauerte zwanzig Minuten und endete erst, nachdem jemand entschieden hatte, einen bestimmten Knoten zu beenden. Ein weiterer betraf die Flusssteuerung, den Mechanismus, der eingehende Arbeit verlangsamt, wenn Clustermitglieder nicht mithalten können: Schreibvorgänge überschritten ihr Zeitlimit, während der Zähler für gesendete Flusssteuerungsnachrichten bei 0 blieb. Das erwartete Signal machte den Stillstand daher nicht sichtbar.
Percona argumentiert, dass solche Fehler häufig außerhalb der Write-Set-Replikation von Galera entstehen, die die durch Datenbanktransaktionen vorgenommenen Änderungen verteilt. Beispiele sind flashcache, eine Komponente zum Zwischenspeichern von Speicherdaten; eine überschriebene Konfigurationszeile für Optionen des Replikationsproviders; DNS, der Dienst zur Auflösung von Namen in Adressen, der auf die falsche Netzwerkschnittstelle verweist; und eine Firewall, die Kommunikation nur in einer Richtung zulässt. In einem anderen Fall musste ein Team, das wiederholte Neustarts in Kubernetes untersuchte – einer Software zur Koordination von Anwendungscontainern –, den Quellcode seines Operators lesen, also der Automatisierung, die die Datenbank verwaltet. Diese Beispiele erklären, warum die mittlere Wiederherstellungszeit, also die Zeit bis zur Wiederaufnahme des Dienstes, stärker von der Ursachensuche als von der eigentlichen Behebung bestimmt sein kann.
Der im Rahmen des Enterprise-Datenbankangebots des Anbieters empfohlene Migrationsweg führt zum Galera-Cluster seiner alternativen Datenbank. Das ist nicht einfach eine neue Supportvereinbarung für dieselbe Datenbank. Wie Percona anmerkt, hat die alternative Datenbank andere Systemtabellen, in denen interne Datenbankinformationen gespeichert werden, und ein grundlegend anderes Datenwörterbuch, also den Katalog zur Beschreibung von Datenbankobjekten. Die Migrationshinweise der alternativen Datenbank verlangen außerdem, Benutzerberechtigungen – die den Zugriff regelnden Rechte – systematisch neu anzulegen. Für Organisationen, die bei der ursprünglichen Datenbank bleiben möchten, machen diese Unterschiede die Wahl zu einer Architekturentscheidung statt zu einer Vertragsverlängerung.
Percona stellt zwei Alternativen vor, beides kommerzielle Angebote eines Anbieters, der ein eigenes Interesse an der Entscheidung hat. Sein Datenbanksupport deckt einen bestehenden Galera-Cluster der ursprünglichen Datenbank ab, ohne Migration, Plattformwechsel oder Neuerstellung der Berechtigungen. Percona wirbt mit erfahrenen Ingenieuren für die ursprüngliche Datenbank, die über Teams in verschiedenen Zeitzonen rund um die Uhr an 365 Tagen im Jahr erreichbar sind und sowohl bei der Ersteinschätzung von Störungen als auch beratend helfen. Diese Beratung umfasst die Optimierung der Replikationsschnittstelle, also die Anpassung der Schnittstelle zwischen der ursprünglichen Datenbank und Galera; die DDL-Strategie, also die Planung von Änderungen an der Datenbankstruktur; die Verteilung von Schreibvorgängen; und die Quorum-Auslegung, also die Festlegung, wie genügend Knoten darüber übereinstimmen, dass der Cluster weiterarbeiten darf. Für seinen Premium-Tarif bewirbt Percona vertraglich zugesicherte Erstreaktionszeiten von bis zu nur 15 Minuten bei Vorfällen der Schweregradstufe 1. Eine zugesicherte Erstreaktionszeit ist keine Garantie für die Zeit bis zur Behebung.
Die andere Option ist die von Percona gepflegte Cluster-Distribution. Sie kombiniert Perconas Distribution des ursprünglichen Datenbankservers mit Perconas eigenem Fork der Galera-Bibliothek, einer separat gepflegten Version, die in einem öffentlichen Repository verfügbar ist. Percona beschreibt sie als kompatibel mit der Community Edition der ursprünglichen Datenbank und erklärt, dass Datenbankschemata, also die Definitionen von Tabellen und ihren Beziehungen, sowie Systemtabellen und Benutzerkonten unverändert übernommen werden. Auch das Verhalten der Replikationsschnittstelle, die Werkzeuge, Konnektoren und das weitere Ökosystem sollen vertraut bleiben. Eine öffentlich zugängliche Migrationsanleitung in zehn Schritten lässt sich eigenständig durcharbeiten. Dies sind Kompatibilitätsaussagen von Percona, kein Nachweis dafür, dass jede Installation ohne Überprüfung umgezogen werden kann.
Percona begründet den Nutzen seiner gepflegten Cluster-Distribution mit der fortlaufenden Wartung der Clusterschicht. Das Unternehmen nennt Arbeiten am inkrementellen Zustandstransfer (IST), der einem wiederherzustellenden Knoten die verpassten Änderungen übermittelt, und am Zustandstransfer per Snapshot (SST), der eine vollständige Datenkopie bereitstellt. Weitere Bereiche sind der Knotenausschluss, also das Entfernen eines Mitglieds aus dem Cluster; die Flusssteuerung; und DDL bei gleichzeitig laufenden Schreibvorgängen. Das Unternehmen verweist auf vierteljährliche öffentliche Versionshinweise mit Jira-Vorgangskennungen, anhand derer einzelne Fehlerbehebungen nachverfolgt werden. Die bereitgestellte Quelle enthält eine Abbildung einer Versionstabelle, macht deren Inhalt aber nicht zugänglich. Einzelne Fehlerbehebungen oder Kennungen lassen sich deshalb aus diesem Text nicht ermitteln.
Laut Percona reicht dieser Veröffentlichungsrhythmus bis 2012 zurück und erstreckt sich über die Versionen 5.5, 5.6, 5.7, 8.0 und inzwischen 8.4, wobei parallel weiterhin Veröffentlichungen für die Versionsreihe 8.0 erscheinen. Nach Angaben des Unternehmens haben in den vorangegangenen 90 Tagen knapp 4.000 Host-Instanzen seiner gepflegten Cluster-Distribution außerhalb von Kubernetes Telemetriedaten gemeldet, also automatisch übermittelte Nutzungsinformationen. Separat berichtet es, dass der Operator der gepflegten Cluster-Distribution in Tausenden weiteren Kubernetes-Installationen läuft. Dies sind Angaben des Anbieters, keine unabhängig erhobenen Nutzerzahlen oder Zuverlässigkeitsmessungen. Percona verweist außerdem auf jüngste Arbeiten zur Inspektion des Replikationscaches, also zur Untersuchung von Galeras Zwischenspeicher replizierter Änderungen, sowie zur standortübergreifenden Replikation im Operator, die Kopien über mehrere Standorte hinweg koordiniert.
Für Kunden seines Migrationsdienstes beschreibt Percona eine Testumgebung für das Zielsystem und einen Vergleich des Verhaltens der Replikationsschnittstelle mit dem bestehenden Cluster. Ziel ist es, vor einer verbindlichen Entscheidung zu beobachten, wie das Ersatzsystem mit denselben Fehlern umgeht. Der Dienst umfasst außerdem einen dokumentierten Rückkehrplan, eine geplante Umstellung mit Unterstützung außerhalb der regulären Arbeitszeiten und eine Zustandsprüfung einige Wochen nach Beginn des Produktivbetriebs. Das sind nützliche Bewertungskriterien für jeden Migrationsvorschlag: Die Kompatibilität sollte anhand der tatsächlichen Arbeitslast und des Verhaltens bei Fehlern geprüft werden, mit einem festgelegten Rückweg für den Fall, dass der Umzug scheitert.
Die verwalteten Datenbanken und die Überwachung von AEU Data sind für diese betriebliche Herausforderung relevant. Kunden sollten jedoch die Support- und Wartungsregelungen für ihre konkrete Clustersoftware überprüfen. Die übergreifende Erkenntnis lautet, zwei Fragen voneinander zu trennen: Wer hilft bei der Diagnose des nächsten Ausfalls, und wer pflegt den Code, der korrigiert werden muss? Support für einen bestehenden Galera-Cluster der ursprünglichen Datenbank kann Zeit verschaffen; die Migration zu einer gepflegten Distribution schließt die Lücke bei der Softwarewartung. Keine der beiden Optionen macht Ausfälle unmöglich. Bleiben jedoch beide Fragen unbeantwortet, wird aus einer schwierigen Diagnose ein längerfristiges Betriebsrisiko.