MariaDB Galera Cluster: bugs críticos que todo CTO debe saber

Lo que el análisis Jepsen revela sobre MariaDB Galera Cluster 12.1.2

El 16 de marzo de 2026, Kyle Kingsbury — fundador de Jepsen, la referencia global en verificación empírica de bases de datos distribuidas — publicó un análisis exhaustivo sobre MariaDB Galera Cluster 12.1.2. Las conclusiones son contundentes: el sistema pierde transacciones confirmadas en al menos dos escenarios documentados, exhibe anomalías de aislamiento incluso en clústeres sanos y no cumple el nivel de aislamiento que su propia documentación promete. Para cualquier founder o CTO que tenga esta base de datos en producción, ignorar estos hallazgos tiene un costo real.

¿Qué es MariaDB Galera Cluster y qué promete?

MariaDB es uno de los motores SQL de código abierto más populares del mundo, nacido como fork de MySQL. Su módulo de alta disponibilidad, Galera Cluster, convierte un conjunto de nodos individuales en un clúster activo-activo con replicación síncrona certificada. En 2025, MariaDB adquirió Codership Oy — la empresa que originalmente desarrolló Galera —, consolidando así el control del roadmap tecnológico bajo un mismo paraguas.

La documentación oficial afirma que Galera garantiza «no lost transactions», que las transacciones se replican «instantly to all other nodes» y que el nivel de aislamiento está «entre Serializable y Repeatable Read». Son promesas muy serias. Y el análisis de Jepsen demuestra que, en la práctica, ninguna de ellas se cumple de forma confiable.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Los cuatro bugs críticos encontrados (todos sin resolver)

MDEV-38974: Pérdida de escrituras en caída coordinada de nodos

Con la configuración recomendada por MariaDB — innodb_flush_log_at_trx_commit=0 — el clúster perdió transacciones confirmadas cuando varios nodos cayeron en rápida sucesión. En una prueba de un minuto, nueve valores escritos en tres filas distintas desaparecieron tras el reinicio del clúster. La ironía: la propia documentación de MariaDB describía este parámetro como «una opción más segura y recomendada con Galera Cluster». La razón técnica es que con valor 0, los datos no se sincronizan al disco antes de confirmar la transacción; si todos los nodos caen antes de que el sistema operativo vacíe el buffer, los datos se pierden para siempre. Cambios de refrigeración, cortes de red o fallos de hardware coordinados son escenarios reales en producción.

MDEV-38976: Pérdida de escrituras con caídas de proceso y particiones de red

Incluso configurando innodb_flush_log_at_trx_commit=1 — la opción más segura —, Jepsen documentó pérdidas ocasionales de transacciones confirmadas durante tests con caídas de proceso y particiones de red. En un ejemplo concreto, la clave 410 perdió los veinticinco elementos escritos durante los últimos 19 segundos de operación y comenzó desde cero. Este bug ocurre con baja frecuencia (una vez cada pocas horas de prueba), pero la pérdida de escrituras confirmadas es inaceptable en sistemas financieros, de inventario o cualquier dominio donde la consistencia sea crítica.

MDEV-38977: Lost Update (Actualización Perdida) en clústeres sanos

Incluso sin introducir ningún tipo de falla, MariaDB Galera Cluster exhibe la anomalía P4 (Lost Update). En el modelo formal de Berenson et al., esto ocurre cuando una transacción T1 lee un dato, T2 modifica ese mismo dato, y luego T1 sobreescribe la modificación de T2 sin haberla visto. El efecto: uno de los dos commits simplemente desaparece como si nunca hubiera ocurrido. Esta anomalía viola directamente Snapshot Isolation y también Repeatable Read cuando el acceso es por clave primaria. Los patrones read-modify-write — usados masivamente por ORMs como ActiveRecord, Hibernate o SQLAlchemy — son potencialmente inseguros sobre este clúster.

MDEV-38999: Stale Read en operación normal

Cada pocos minutos de operación normal, sin inyección de fallas, el sistema exhibió Stale Read: una transacción confirmada y reconocida al cliente no era visible para una segunda transacción iniciada inmediatamente después. Esto contradice directamente la promesa de replicación «instantánea y sin lag de réplica» que figura en la documentación de MariaDB.

La tabla de bugs: todos sin resolver a la fecha de publicación

Es importante destacar que los cuatro bugs reportados permanecen sin resolver al momento de la publicación del análisis (marzo de 2026):

MDEV-38974 — Pérdida de escrituras confirmadas | Requiere: caídas coordinadas de procesos | Estado: sin resolver
MDEV-38976 — Pérdida de escrituras confirmadas | Requiere: caídas + particiones de red | Estado: sin resolver
MDEV-38977 — Lost Update (P4 / G2-item) | Requiere: ninguna falla | Estado: sin resolver
MDEV-38999 — Stale Read | Requiere: ninguna falla | Estado: sin resolver

El contexto más amplio: MariaDB y el futuro de Galera

Estos hallazgos técnicos se producen en un momento de turbulencia corporativa para el ecosistema Galera. En febrero de 2026, MariaDB anunció que MariaDB Community Server 12.3 dejaría de incluir las librerías de Galera Cluster. La reacción de la comunidad fue inmediata y masiva: desarrolladores, DBAs y empresas usuarias alzaron la voz, y pocos días después MariaDB dio marcha atrás, comprometiendo la continuidad de Galera en la versión comunitaria. La MariaDB Foundation emitió un comunicado explicitando la responsabilidad compartida entre la Fundación y MariaDB plc en el mantenimiento del proyecto.

Este contexto institucional refuerza la preocupación técnica: si el equipo detrás del producto consideró eliminar Galera y ahora debe responder a cuatro bugs críticos sin parche, los equipos de ingeniería tienen razones sólidas para evaluar sus opciones.

¿Qué deberían hacer los founders y CTOs ahora mismo?

Acción inmediata si usas MariaDB Galera en producción

La recomendación principal de Jepsen es clara: configura innodb_flush_log_at_trx_commit=1 de inmediato. Esto reduce significativamente el riesgo de pérdida de datos por caídas coordinadas. Sin embargo, no elimina los bugs MDEV-38976, MDEV-38977 ni MDEV-38999. Si tu aplicación usa patrones read-modify-write — como la mayoría de los frameworks modernos —, debes asumir que existe riesgo de Lost Update hasta que MDEV-38977 tenga fix oficial.

Evalúa alternativas según tu caso de uso

No existe la base de datos perfecta, pero sí existen mejores herramientas para cada contexto. Una comparativa orientativa para founders:

PostgreSQL + Patroni: Modelo líder-seguidor con replicación streaming. Mejor consistencia single-writer; requiere manejo de failover. Ideal para cargas de escritura concentradas.
CockroachDB: SQL distribuido con Raft, Serializable por defecto y reintentos automáticos de transacciones. Mayor overhead operacional, pero garantías formales sólidas. Buena opción para cargas geo-distribuidas.
PlanetScale / Vitess: Sharding de MySQL a gran escala. Garantías por shard; consistencia global más débil. Ideal para escala masiva de lecturas.
MariaDB Galera con mitigaciones: Válida para cargas de baja contención y equipos con expertise en el sistema, siempre con innodb_flush_log_at_trx_commit=1, lógica de retry en la aplicación y monitoreo activo de wsrep_*.

Principios de consistencia que todo CTO debería conocer

Los bugs encontrados por Jepsen no son exclusivos de MariaDB. Son manifestaciones de problemas clásicos en bases de datos distribuidas que cualquier equipo técnico debería entender: Snapshot Isolation vs. Serializable, el riesgo de Lost Update en sistemas multi-master, el impacto real de fsync en durabilidad, y la diferencia entre consistencia «eventual» y consistencia «strong». Construir sobre supuestos de consistencia incorrectos puede significar dinero perdido, datos duplicados o auditorías fallidas — exactamente los escenarios simulados en el banco test de Jepsen.

Conclusión

El análisis de Jepsen sobre MariaDB Galera Cluster 12.1.2 es una lectura obligatoria para cualquier CTO o founder que opere infraestructura SQL crítica. Las conclusiones son técnicamente rigurosas, reproducibles y — quizás lo más importante — honestas: cuatro bugs sin resolver, incluyendo pérdida de transacciones confirmadas y anomalías de aislamiento en operación normal. El sistema no cumple las garantías que su documentación promete.

La buena noticia: los problemas son conocidos, hay mitigaciones parciales disponibles hoy, y la comunidad de bases de datos distribuidas tiene alternativas maduras. El primer paso es siempre la misma disciplina de cualquier buen founder: entender exactamente qué garantías te ofrece tu stack de infraestructura, no las que dice el marketing, sino las que demuestra la evidencia.

Profundiza estos temas con nuestra comunidad de founders tech — comparte tu stack, aprende de quienes ya enfrentaron estos desafíos en producción.

Aprender con founders