Warum MariaDB Operator 25.10 ein großer Wurf für Stateful Workloads auf Kubernetes ist
Datenbanken in Kubernetes zu betreiben, fühlte sich schon immer ein bisschen an, als würde man ein eckiges Teil in ein rundes Loch pressen wollen. Kubernetes wurde für zustandslose Anwendungen entworfen, und Datenbanken – diese lästigen, zustandsbehafteten, speicherhungrigen, störanfälligen Kreaturen – wurden im Cloud-native-Ökosystem lange wie Bürger zweiter Klasse behandelt.
Doch mit der Veröffentlichung von MariaDB Operator 25.10 beginnt sich das zu verschieben.
Dieses Update ist nicht einfach nur eine höhere Versionsnummer oder ein Routine-Sicherheitspatch. Es ist ein bedeutender Sprung nach vorn, besonders für Teams, die Stateful Workloads wie MariaDB in Kubernetes betreiben wollen, ohne halbgare Lösungen mit Klebeband zusammenzuhalten. Dieses Release führt asynchrone Replikation als vollständig unterstütztes Feature ein, ergänzt automatisierte Replica-Recovery und bringt mehrere clevere operative Verbesserungen mit, die den Betrieb produktionsreifer MariaDB-Cluster in Kubernetes nicht nur möglich – sondern vernünftig machen.
Asynchrone Replikation wird GA – und ist tatsächlich solide
Das Kernfeature hier 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 dabei 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 schon seit Ewigkeiten. Wichtig ist aber, dass MariaDB Operator es jetzt tiefgreifend versteht. Sie definieren ein einfaches Kubernetes-Manifest, schalten die Replikation ein, und schwupps – schon 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. Sie müssen nicht babysitten. Sie definieren einfach den gewünschten Zustand und lassen den Operator die Drecksarbeit erledigen.
Failover, dem Sie wirklich vertrauen können
Ein weiterer großer Gewinn? Automatisiertes 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. Das ist kein wackeliger Hack, der die Daumen drückt 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.
Hier ein Beispiel, wie das während eines Failovers aussieht:
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
Dieser Übergang dauert Sekunden. Es ist genau die Art von Zero-Touch-Recovery, die sich die meisten Teams beim manuellen Datenbank-Management wünschen – nur dass sie jetzt fest eingebaut ist.
Sie können das Failover-Verhalten sogar mit Einstellungen wie autoFailoverDelay steuern, um festzulegen, 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: Replica-Korruption.
Jeder, der 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". Das ist ein stiller Killer, der Ihren Cluster in einem seltsamen Schwebezustand zurücklässt.
MariaDB Operator 25.10 löst das mit automatisierter Replica-Recovery über ein Konstrukt namens PhysicalBackup. Wenn eine Replica sich nicht normal erholen kann, löst der Operator einen Recovery-Flow aus, der einen Snapshot auf Volume-Ebene von einer gesunden Replica nimmt und ihn auf die defekte zurückspielt. Alles 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 in der Regel schnell genug, dass Sie nicht in Panik geraten müssen. Für Teams mit produktionsreifen Workloads ist das ein Segen. Es macht aus Replica-Recovery statt einem 30-minütigen Feuerwehreinsatz ein Nicht-Ereignis.
Intelligenteres, sichereres Scaling und Backups
Dieses Release hört nicht bei Failover und Recovery auf. 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.
Das gibt Teams 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 richtige Wahl zu treffen ist so einfach wie ein anderes Template einzustecken.
Die Handschrift der Community ist überall zu erkennen
Es lohnt sich zu erwähnen, dass vieles von dem, was 25.10 so gut macht, aus Feedback aus der echten Praxis stammt. 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. Diese Art von Weiterentwicklung ist selten bei Projekten, die für alle alles sein wollen.
Nicht perfekt – aber nah dran
Es gibt noch Luft nach oben. Aktuell unterstützt der Operator Replikation nur innerhalb eines einzelnen Kubernetes-Clusters, nicht über Cluster oder Regionen hinweg. Das ist eine Einschränkung für Teams, die Multi-Region-Failover-Systeme bauen. Aber angesichts des Entwicklungstempos wirkt Cross-Cluster-Support eher wie eine Frage des „Wann", nicht des „Ob".
Dazu kommen die üblichen Vorbehalte bei der Performance. Wenn Sie Kubernetes on-prem betreiben, ist lokaler Storage Pflicht. Vernetzte Volumes können zum Flaschenhals werden, besonders bei schreiblastigen Workloads. Und wie es der Maintainer formulierte: „Keine Annahmen treffen – sysbench laufen lassen."
Trotzdem bringt MariaDB Operator 25.10, selbst mit diesen Einschränkungen, ein Maß an Vertrauen mit, das Stateful Workloads in Kubernetes bisher oft gefehlt hat. Es ist kein angeflanschtes Experiment mehr. Es ist produktionsreif, durchdacht gebaut und wird von einer Community getragen, der es spürbar wichtig ist.
TL;DR
MariaDB Operator 25.10 unterstützt nicht einfach nur asynchrone Replikation. Es 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.
Wenn Sie auf ein Zeichen gewartet haben, dass der Betrieb einer Datenbank in k8s nicht leichtsinnig ist, dann ist das dieses Zeichen.