Was MariaDB Operator 25.10 für Stateful Workloads auf Kubernetes bringt

Datenbanken in Kubernetes zu betreiben fühlte sich schon immer ein bisschen an, als wollte man ein eckiges Teil in ein rundes Loch pressen. Kubernetes wurde für zustandslose Anwendungen entworfen, und Datenbanken, diese lästigen, zustandsbehafteten, speicherhungrigen und störanfälligen Kreaturen, wurden im Cloud-native-Ökosystem lange wie Bürger zweiter Klasse behandelt.

Mit der Veröffentlichung von MariaDB Operator 25.10 beginnt sich das zu verschieben.

Das Update bringt mehr als eine höhere Versionsnummer oder einen Routine-Sicherheitspatch. Es ist ein großer Schritt nach vorn, besonders für Teams, die Stateful Workloads wie MariaDB in Kubernetes betreiben wollen, ohne halbgare Lösungen mit Klebeband zusammenzuhalten. Das Release macht asynchrone Replikation zu einem vollständig unterstützten Feature, ergänzt automatisierte Replica-Recovery und bringt mehrere clevere operative Verbesserungen mit. Damit wird der Betrieb produktionsreifer MariaDB-Cluster in Kubernetes möglich und sogar vernünftig.

Asynchrone Replikation wird GA und ist tatsächlich solide

Das zentrale Feature ist die allgemeine Verfügbarkeit (General Availability, GA) der asynchronen Replikation. Das klingt vielleicht wenig aufregend, außer Sie haben schon mal um 3 Uhr morgens zugesehen, wie eine Datenbank aus dem Ruder läuft. Für die meisten Nutzer bedeutet asynchrone Replikation etwas ziemlich Einfaches: Ein primärer Datenbankserver übernimmt alle Schreibvorgänge, und eine oder mehrere Replicas ziehen nach und übernehmen die Änderungen, so schnell sie können.

Bleeding-Edge-Technologie ist das nicht, MySQL und MariaDB unterstützen das seit Ewigkeiten. Neu ist, dass MariaDB Operator es jetzt tiefgreifend versteht. Sie definieren ein einfaches Kubernetes-Manifest, schalten die Replikation ein, und schwupps haben Sie ein Primary-Replica-Setup.

apiVersion: k8s.mariadb.com/v1alpha1
kind: MariaDB
metadata:
  name: mariadb-repl
spec:
  storage:
    size: 1Gi
    storageClassName: rook-ceph
  replicas: 3
  replication:
    enabled: true

Das war's. Im Hintergrund legt der Operator Benutzer an, verwaltet Zugangsdaten, synchronisiert die Binärlogs und überwacht den Replikations-Lag. Babysitten müssen Sie nichts: Sie definieren den gewünschten Zustand und lassen den Operator die Drecksarbeit erledigen.

Failover, dem Sie wirklich vertrauen können

Ein weiterer großer Gewinn ist das automatisierte Primary-Failover.

Wenn Ihr Primary-Pod stirbt, und irgendwann wird er das, wählt der Operator automatisch die aktuellste Replica aus und befördert sie zum Primary. Dabei drückt er nicht bloß die Daumen und hofft, dass der neue Primary alle Schreibvorgänge hat. Der Operator prüft den Replikations-Lag und den Status der Relay-Log-Anwendung, um sicherzustellen, dass der Kandidat sauber ist.

So sieht das während eines Failovers aus:

NAME           READY   STATUS                                  PRIMARY          UPDATES
mariadb-repl   False   Switching primary to 'mariadb-repl-1'   mariadb-repl-0   ReplicasFirstPrimaryLast
...
NAME           READY   STATUS    PRIMARY          UPDATES
mariadb-repl   True    Running   mariadb-repl-1   ReplicasFirstPrimaryLast

Der Übergang dauert Sekunden. Genau diese Art von Zero-Touch-Recovery wünschen sich die meisten Teams beim manuellen Datenbank-Management, und jetzt ist sie fest eingebaut.

Mit Einstellungen wie autoFailoverDelay können Sie sogar steuern, wie aggressiv das System einen neuen Primary befördert. Das ist enorm wichtig für High-Availability-Setups, bei denen sich Uptime in Dollar pro Sekunde bemisst.

Replica-Recovery, die nicht nervt

Reden wir über den Elefanten im Cluster, die Replica-Korruption.

Wer schon mit asynchroner Replikation zu tun hatte, kennt den Schmerz von Fehlercode 1236, die gefürchtete Situation, in der „die Replica nicht aufholen kann, weil der Primary die Binärlogs bereinigt hat". Dieser Fehler fällt oft lange nicht auf und lässt Ihren Cluster in einem seltsamen Schwebezustand zurück.

MariaDB Operator 25.10 löst das mit automatisierter Replica-Recovery über ein Konstrukt namens PhysicalBackup. Kann sich eine Replica nicht normal erholen, startet der Operator einen Recovery-Flow, der einen Snapshot auf Volume-Ebene von einer gesunden Replica nimmt und ihn auf die defekte zurückspielt, ganz ohne manuellen Eingriff.

Und das Beste daran: Es funktioniert tatsächlich.

kubectl get mariadb
NAME           READY   STATUS                PRIMARY
mariadb-repl   False   Recovering replicas   mariadb-repl-1
...
kubectl get mariadb
NAME           READY   STATUS    PRIMARY
mariadb-repl   True    Running   mariadb-repl-1

Die Recovery-Zeit hängt von Ihrem Storage-Treiber und der Datenmenge ab, ist aber meist kurz genug, dass Sie nicht in Panik geraten müssen. Für Teams mit produktionsreifen Workloads ist das ein Segen, denn aus einem 30-minütigen Feuerwehreinsatz wird ein Nicht-Ereignis.

Intelligenteres, sichereres Scaling und Backups

Das Release geht über Failover und Recovery hinaus. Es bietet auch flexible Strategien fürs Scale-out, einschließlich Unterstützung für verschiedene Backup-Methoden. Sie können schnelle, lokale VolumeSnapshots für rasches Scaling nutzen oder zu mariadb-backup wechseln, wenn es um längerfristige Haltbarkeit geht.

Teams bekommen dadurch mehr Kontrolle darüber, wie sie Performance und Zuverlässigkeit ausbalancieren. Sie können zum Beispiel eine PhysicalBackup-Spec für nächtliche S3-Backups pflegen und eine weitere für sofortige, snapshot-basierte Recovery. Der Operator unterstützt beides, und die Wahl ist so einfach, wie ein anderes Template einzustecken.

Die Handschrift der Community ist überall zu erkennen

Vieles von dem, was 25.10 so gut macht, stammt aus Feedback aus der echten Praxis. Nutzer in der Open-Source-Community meldeten Probleme mit der frühen Replikations-Unterstützung, reichten manuelle Recovery-Runbooks ein und drängten die Maintainer, das operative Erlebnis zu verfeinern.

Die Maintainer, allen voran mmontes11, der einen Großteil der Entwicklung anzuführen scheint, verdienen Anerkennung dafür, dass sie zuhören und iterieren. Man spürt den Unterschied zwischen einem Feature, das „in der Blase" entstanden ist, und einem, das im echten Produktionseinsatz geschmiedet wurde.

Wie ein Nutzer in der Release-Diskussion anmerkte, existieren viele Features heute, weil Leute immer wieder ihre Cluster kaputt gemacht haben und bessere Recovery-Wege wollten. So eine Weiterentwicklung sieht man selten bei Projekten, die für alle alles sein wollen.

Nicht perfekt, aber nah dran

Luft nach oben gibt es trotzdem. Aktuell unterstützt der Operator Replikation nur innerhalb eines einzelnen Kubernetes-Clusters, nicht über Cluster oder Regionen hinweg. Für Teams, die Multi-Region-Failover-Systeme bauen, ist das eine Einschränkung. Angesichts des Entwicklungstempos scheint Cross-Cluster-Support aber eher eine Frage des „Wann" als des „Ob" zu sein.

Dazu kommen die üblichen Vorbehalte bei der Performance. Wenn Sie Kubernetes on-prem betreiben, ist lokaler Storage Pflicht, denn vernetzte Volumes können zum Flaschenhals werden, besonders bei schreiblastigen Workloads. Oder wie es der Maintainer formulierte: „Keine Annahmen treffen, sysbench laufen lassen."

Selbst mit diesen Einschränkungen bringt MariaDB Operator 25.10 ein Maß an Vertrauen mit, das Stateful Workloads in Kubernetes bisher oft gefehlt hat. Das Projekt ist aus dem Experimentierstadium heraus, produktionsreif, durchdacht gebaut und wird von einer Community getragen, der es spürbar wichtig ist.

TL;DR

MariaDB Operator 25.10 unterstützt asynchrone Replikation und bringt sie so zum Laufen, wie Sie es sich wünschen: automatisch, intelligent und resilient. Mit Features wie:

• allgemeine Verfügbarkeit (GA) der asynchronen Replikation
• automatisiertes Failover zur aktuellsten Replica
• snapshot-basierte Replica-Recovery bei Fehlercode 1236
• flexible Backup-Strategien für unterschiedliche Anwendungsfälle

…ist das ein Meilenstein-Release für alle, die Stateful Workloads mit minimalem Drama nach Kubernetes verschieben wollen.

Falls Sie auf ein Zeichen gewartet haben, dass der Betrieb einer Datenbank in k8s nicht leichtsinnig ist: Hier ist es.