Kyle Kingsbury, el investigador detrás de Jepsen, publicó el 16 de marzo de 2026 un análisis exhaustivo sobre MariaDB Galera Cluster 12.1.2. El veredicto es claro y sin matices: el sistema pierde transacciones confirmadas en al menos dos escenarios documentados, exhibe anomalías de aislamiento incluso en clústeres sin fallos activos, y no cumple las garantías que su propia documentación promete. Si tienes esta base de datos en producción, este análisis te cambia el nivel de riesgo que estás asumiendo.
Jepsen es el estándar de facto en verificación empírica de sistemas distribuidos. Sus análisis han expuesto vulnerabilidades en ecosistemas de datos abiertos y en prácticamente cada motor de base de datos relevante. Cuando Jepsen habla, la comunidad escucha.
¿Qué garantiza Galera — y qué falla en la práctica?
MariaDB Galera Cluster es el módulo de alta disponibilidad activo-activo de MariaDB, nacido como fork de MySQL. En 2025, MariaDB adquirió Codership Oy — la empresa que desarrolló Galera originalmente — consolidando el roadmap bajo un solo paraguas. La documentación oficial promete tres cosas muy concretas:
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀- «No lost transactions»
- Replicación «instantly to all other nodes»
- Nivel de aislamiento «entre Serializable y Repeatable Read»
El análisis de Jepsen demuestra que ninguna de las tres se cumple de forma fiable.
Los cuatro bugs críticos — sin parche a la fecha de publicación
Todos los bugs reportados permanecen sin resolver al momento del análisis:
MDEV-38974 — Pérdida de escrituras en caídas coordinadas
Con la configuración recomendada por MariaDB (innodb_flush_log_at_trx_commit=0), el clúster pierde transacciones confirmadas cuando varios nodos caen en rápida sucesión. En una prueba de un minuto, nueve valores escritos en tres filas distintas desaparecieron. La ironía: la propia documentación describía ese parámetro como «una opción más segura y recomendada con Galera Cluster».
MDEV-38976 — Pérdida de escrituras con caídas de proceso y particiones de red
Incluso con innodb_flush_log_at_trx_commit=1 — la opción más segura — Jepsen documentó pérdidas ocasionales de transacciones confirmadas. Baja frecuencia, pero inaceptable en sistemas financieros o de inventario.
MDEV-38977 — Lost Update en clústeres sin fallos activos
Sin introducir ninguna falla, el sistema exhibe la anomalía P4 (Lost Update): T1 lee un dato, T2 lo modifica, T1 sobreescribe sin haber visto el cambio de T2. Uno de los dos commits desaparece. Esto afecta directamente los patrones read-modify-write — los que usan ORMs como ActiveRecord, Hibernate o SQLAlchemy por defecto.
MDEV-38999 — Stale Read en operación normal
Cada pocos minutos, una transacción confirmada no es visible para la siguiente transacción iniciada inmediatamente después. Contradice directamente la promesa de replicación «instantánea y sin lag».
El contexto corporativo complica el panorama
Estos hallazgos llegan en un momento de turbulencia institucional. En febrero de 2026, MariaDB anunció que Community Server 12.3 dejaría de incluir las librerías de Galera. La respuesta de la comunidad fue inmediata y masiva. MariaDB dio marcha atrás días después, comprometiendo continuidad, pero el episodio revela una tensión real entre el proyecto y su sostenibilidad a largo plazo.
La MariaDB Foundation emitió un comunicado explicitando responsabilidades compartidas. Cuatro bugs sin parche más incertidumbre institucional es una combinación incómoda para cualquier equipo de infraestructura.
¿Qué hacer ahora si usas Galera en producción?
La recomendación inmediata de Jepsen: configura innodb_flush_log_at_trx_commit=1 ahora. Reduce el riesgo de MDEV-38974, pero no resuelve los otros tres bugs.
Dependiendo de tu caso de uso, hay opciones más sólidas:
- PostgreSQL + Patroni — líder-seguidor con replicación streaming. Mejor consistencia para escrituras concentradas. Mayor predictibilidad.
- CockroachDB — SQL distribuido con Raft, Serializable por defecto y reintentos automáticos. Overhead operacional mayor, pero garantías formales más rigurosas.
- MariaDB Galera con mitigaciones — válida para cargas de baja contención con equipos que conocen el sistema, siempre con
trx_commit=1, lógica de retry en la aplicación y monitoreo activo dewsrep_*.
Por qué importa más allá del bug específico
El problema de fondo no es solo MariaDB. Es que muchos equipos asumen garantías de consistencia que no están probadas empíricamente. Los bugs encontrados por Jepsen — Lost Update, Stale Read, pérdida de durabilidad — son manifestaciones de problemas clásicos en bases de datos distribuidas: la diferencia entre Snapshot Isolation y Serializable, el impacto real de fsync, el riesgo de multi-master sin coordinación fuerte.
Como documenta el patrón de código plausible-pero-incorrecto en LLMs, los sistemas de infraestructura también pueden parecer correctos mientras acumulan inconsistencias silenciosas. El stack que no falla en staging puede fallar catástroficamente en producción bajo patrones de carga específicos.
La disciplina es la misma en ambos casos: entender exactamente qué garantías ofrece tu herramienta — no las del marketing, sino las que muestra la evidencia empírica.
