MariaDB Operator 25.10: cargas con estado en Kubernetes
Ejecutar bases de datos en Kubernetes siempre ha parecido un intento de encajar una pieza cuadrada en un agujero redondo. Kubernetes se diseñó para aplicaciones sin estado, y durante mucho tiempo las bases de datos, esas criaturas con estado, hambrientas de disco y sensibles a los fallos, han sido tratadas como ciudadanas de segunda clase en el ecosistema nativo de la nube. Con la llegada de MariaDB Operator 25.10, eso empieza a cambiar.
Esta actualización supone un gran salto, sobre todo para los equipos que quieren ejecutar cargas de trabajo con estado como MariaDB dentro de Kubernetes sin tener que pegar apaños a medias con cinta adhesiva. La versión convierte la replicación asíncrona en una característica con soporte oficial, añade recuperación automática de réplicas e integra varias mejoras operativas inteligentes que hacen que operar clústeres de MariaDB en producción dentro de Kubernetes sea viable y razonable.
La replicación asíncrona llega a GA, y es realmente sólida
La novedad principal es la disponibilidad general (GA) de la replicación asíncrona. Puede que no suene emocionante a menos que hayas visto una base de datos desmoronarse a las 3 AM. Para la mayoría de usuarios, la replicación asíncrona significa algo bastante directo: un servidor de base de datos principal atiende todas las escrituras, y una o más réplicas le siguen el ritmo trayendo los cambios tan rápido como pueden.
Apenas es tecnología de vanguardia, dado que MySQL y MariaDB la han admitido desde hace años. Lo que ha cambiado es que MariaDB Operator ahora la entiende a fondo. Defines un manifiesto sencillo de Kubernetes, activas la replicación y ya tienes una configuración de principal y réplicas.
apiVersion: k8s.mariadb.com/v1alpha1
kind: MariaDB
metadata:
name: mariadb-repl
spec:
storage:
size: 1Gi
storageClassName: rook-ceph
replicas: 3
replication:
enabled: true
Eso es todo. Por debajo, el operador configura usuarios, gestiona credenciales, sincroniza los binary logs y monitoriza el retardo de replicación. No necesitas estar encima vigilándolo: defines el estado deseado y dejas que el operador se encargue del trabajo pesado.
Un failover en el que realmente puedes confiar
El failover automático del nodo principal es otro gran acierto. Si el pod principal se cae, y tarde o temprano ocurrirá, el operador elige automáticamente la réplica más actualizada y la promociona. No cruza los dedos esperando que el nuevo principal tenga todas las escrituras. El operador comprueba el desfase de replicación y el estado de aplicación del relay log para asegurarse de que el candidato esté limpio.
Aquí tienes un ejemplo de cómo se ve durante un failover:
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
Esa transición tarda segundos. Es la clase de recuperación desatendida que la mayoría de equipos deseaba cuando administraba bases de datos manualmente, y ahora viene integrada.
Incluso puedes controlar el comportamiento del failover con parámetros como autoFailoverDelay para ajustar con qué rapidez el sistema promociona un nuevo principal. Eso importa mucho en configuraciones de alta disponibilidad donde el tiempo de actividad se mide en dólares por segundo.
Recuperación de réplicas que de verdad funciona
Luego está el problema que nadie quiere afrontar en el clúster: la corrupción de réplicas. Quien haya lidiado con replicación asíncrona conoce el dolor del error code 1236, la temida situación en la que la réplica no puede alcanzar al principal porque este purgó los binary logs. Es un problema silencioso que deja el clúster en un limbo extraño.
MariaDB Operator 25.10 resuelve esto con la recuperación automática de réplicas mediante un recurso llamado PhysicalBackup. Si una réplica no se puede recuperar con normalidad, el operador activa un flujo de recuperación que toma una snapshot a nivel de volumen de una réplica sana y la restaura en la dañada, todo sin intervención manual. Y lo mejor de todo es que funciona:
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
El tiempo de recuperación depende del controlador de almacenamiento y del tamaño de los datos, pero suele ser lo bastante rápido como para no tener que correr. Para los equipos con cargas de trabajo de producción, esto es una bendición, transformando la recuperación de réplicas de un incendio de 30 minutos en algo rutinario.
Escalado y copias de seguridad más inteligentes y seguros
La versión va más allá del failover y la recuperación. También ofrece estrategias flexibles para escalar horizontalmente, incluyendo soporte para distintos métodos de copia de seguridad. Puedes usar VolumeSnapshots locales y rápidos para un escalado ágil, o cambiar a mariadb-backup para obtener durabilidad a largo plazo.
Eso da a los equipos mayor control sobre el equilibrio entre rendimiento y fiabilidad. Por ejemplo, puedes mantener una especificación de PhysicalBackup para copias nocturnas a S3 y otra para recuperación instantánea basada en snapshots. El operador admite ambas opciones, y elegir la adecuada es tan simple como conectar una plantilla distinta.
La huella de la comunidad está por todas partes
Gran parte de lo que hace destacar a la versión 25.10 proviene de comentarios del mundo real. Usuarios de la comunidad de código abierto reportaron problemas con el soporte inicial de replicación, compartieron runbooks de recuperación manual y empujaron a los mantenedores a pulir la experiencia operativa.
Los mantenedores, especialmente mmontes11, quien parece liderar gran parte del desarrollo, merecen reconocimiento por escuchar e iterar. Se nota la diferencia entre una funcionalidad creada en una burbuja y otra forjada mediante el uso real en producción.
Como señaló un usuario en el debate del lanzamiento, muchas características existen hoy porque la gente rompía sus clústeres y necesitaba mejores rutas de recuperación. Ese tipo de evolución resulta poco habitual en proyectos que intentan abarcarlo todo.
No es perfecto, pero se acerca
Todavía queda margen de mejora. Ahora mismo el operador solo admite replicación dentro de un único clúster de Kubernetes, por lo que la replicación entre clústeres o regiones queda descartada. Es una limitación para equipos que construyen sistemas de failover multirregión, pero viendo el ritmo al que avanza todo, el soporte multiclúster parece más una cuestión de cuándo que de si llegará.
Las advertencias habituales sobre rendimiento también se aplican aquí. Si ejecutas Kubernetes on-premise, el almacenamiento local es imprescindible, porque los volúmenes en red pueden convertirse en un cuello de botella, sobre todo con cargas de trabajo intensivas en escritura. Como dijo el mantenedor: "Don't make any assumptions: run sysbench".
Incluso con esas limitaciones, MariaDB Operator 25.10 aporta un nivel de confianza del que las cargas de trabajo con estado en Kubernetes a menudo han carecido. Ha superado la fase de experimento improvisado para convertirse en algo listo para producción, bien diseñado y respaldado por una comunidad que demuestra interés.
En resumen
MariaDB Operator 25.10 hace que la replicación asíncrona funcione como esperarías: de forma automática, inteligente y resistente. La versión incluye:
- Disponibilidad general de replicación asíncrona
- Failover automático a la réplica más actualizada
- Recuperación de réplicas basada en snapshots ante el error code 1236
- Estrategias flexibles de copia de seguridad para distintos casos de uso
Eso la convierte en una versión clave para quien busque mover cargas con estado a Kubernetes sin complicaciones innecesarias. Si estabas esperando una señal de que ejecutar una base de datos en k8s no es una imprudencia, aquí la tienes.