Cómo armar un cluster MariaDB Galera de 3 nodos

En pocas palabras: Se levanta instalando mariadb-server, galera-4 y rsync en tres nodos, configurando 60-galera.cnf con los IPs del cluster y abriendo los puertos 3306, 4567, 4568 y 4444. El primer nodo se inicializa con galera_new_cluster; los otros dos sincronizan vía rsync (SST) al arrancar MariaDB normalmente.

Un cluster MariaDB Galera de 3 nodos en bare metal se levanta con paquetes mariadb-server, galera-4 y rsync, un archivo 60-galera.cnf por servidor y un bootstrap inicial con galera_new_cluster. El resultado, según la guía técnica de eServers, es replicación síncrona multi-maestro sin punto único de falla.

MariaDB Galera Cluster es una tecnología de replicación síncrona multi-maestro para MariaDB, basada en la API wsrep (Write Set Replication), donde cada transacción se certifica en todos los nodos antes de confirmarse. A diferencia de la replicación master-slave clásica, cualquier nodo acepta lecturas y escrituras al mismo tiempo, sin depender de un único servidor central.

¿Cómo funciona la replicación síncrona de Galera comparada con master-slave tradicional?

La replicación síncrona de Galera confirma una transacción solo cuando todos los nodos del cluster la certificaron, así que no hay pérdida de datos en un failover. La replicación master-slave asíncrona de MySQL/MariaDB, en cambio, deja que el maestro confirme la escritura sin esperar a las réplicas, lo que genera lag y riesgo real de perder las últimas transacciones si el maestro cae.

Ejemplo hipotético (ilustrativo, no un caso real reportado): imaginemos un e-commerce con carrito de compras activo, donde el servidor maestro se cae justo después de procesar un pago. Con replicación asíncrona, esa transacción podría no haber llegado todavía al slave, y ahí se perdería el dato. Con Galera esto no debería ocurrir, porque el commit no se confirma hasta que los tres nodos certifican la transacción entre sí.

La contra es obvia: si esperás confirmación de todos los nodos, cada escritura tarda lo que tarde el nodo más lento en responder. Por eso Galera es un fit natural para SaaS y e-commerce donde el downtime o la pérdida de datos no son opción, pero no es gratis en términos de latencia por transacción.

¿Cuándo conviene elegir Galera Cluster y cuándo conviene quedarse con master-slave?

No hay una respuesta única para todos los casos, pero de los propios trade-offs técnicos que documentan las fuentes se pueden sacar algunos criterios de decisión concretos, sin necesidad de un benchmark propio:

• Si la aplicación no tolera perder ni una transacción confirmada en un failover (pagos, inventario, facturación), Galera es la opción más segura: la certificación síncrona hace que un commit exitoso ya esté replicado en todos los nodos.
• Si el patrón de tráfico es mayormente lectura y pocas escrituras concurrentes, el costo extra de latencia por certificación síncrona pesa menos, porque la mayoría de las operaciones no dependen de ese acuerdo entre nodos.
• Si hay muchas escrituras concurrentes desde aplicaciones distintas apuntando a nodos distintos, conviene tener en cuenta el riesgo de conflictos de certificación: dos transacciones que tocan la misma fila en nodos distintos casi al mismo tiempo pueden hacer que una de las dos falle, algo que no ocurre en un esquema master-slave con un único punto de escritura.
• Si la prioridad es minimizar la latencia de escritura individual por sobre la garantía de cero pérdida de datos, y se puede tolerar un lag pequeño más un proceso de failover manual o scripteado, master-slave asíncrono sigue siendo más simple de operar y más rápido por transacción.
• Si el equipo no tiene experiencia operando quórum distribuido, vale la pena considerar que Galera agrega una capa de complejidad operativa (bootstrap, IST/SST, quórum) que un master-slave clásico no tiene.

¿Qué requisitos de infraestructura necesita un cluster Galera en bare metal?

Un cluster Galera de 3 nodos en bare metal necesita servidores dedicados con Ubuntu 22.04 LTS, mínimo 4 núcleos y 8 GB de RAM cada uno, red privada de baja latencia entre nodos e IPs internas estáticas, según los prerequisitos detallados en la guía de eServers.

La topología típica de referencia usa tres IPs fijas: 10.0.0.11 para el nodo de bootstrap, 10.0.0.12 y 10.0.0.13 como miembros. El número impar de nodos no es casualidad: Galera necesita quórum para decidir qué partición del cluster sigue siendo “Primary” en caso de un split de red, y con dos nodos ese criterio de mayoría no funciona. Más contexto en exponer servicios como en un cluster de Kubernetes.

Ejemplo hipotético (cálculo de quórum, deducido del principio de mayoría que documentan las fuentes, no un dato extraído de ellas): en un cluster de N nodos, Galera necesita que más de la mitad de los nodos originales sigan comunicados entre sí para conservar el quórum “Primary”. Con 3 nodos, eso significa tolerar la caída de 1 nodo sin perder quórum, porque 2 de 3 sigue siendo mayoría. Pero no tolera la caída simultánea de 2. Si el objetivo fuera aguantar 2 caídas simultáneas, harían falta 5 nodos y no 3, porque ahí 3 de 5 sigue siendo mayoría. Esto es matemática de quórum por mayoría aplicada al principio de “número impar” que las fuentes mencionan, no una cifra que ellas mismas calculen.

¿Por qué bare metal y no una VM compartida? Porque la certificación síncrona depende de que el I/O de disco y la latencia de red sean predecibles, y en un host compartido con otros tenants eso no está garantizado. Un servidor dedicado con CPU, RAM y disco propios evita que un vecino ruidoso te arruine los tiempos de commit.

La instalación arranca igual en los tres nodos:

• Paquetes base: sudo apt install -y mariadb-server mariadb-client galera-4 rsync. La librería galera-4 es la que habla el protocolo wsrep con los otros nodos.
• Servicio detenido: sudo systemctl stop mariadb antes de tocar la configuración, porque los parámetros de Galera tienen que estar en el archivo antes del primer arranque como miembro del cluster.
• rsync como dependencia: se usa para el State Snapshot Transfer (SST), el mecanismo que sincroniza el dataset completo cuando un nodo se une o se cae y vuelve.

Si vas a exponer el cluster fuera de la red privada en algún momento, mejor ponelo detrás de una capa de protección en vez de abrir los puertos de base de datos directo a internet.

¿Qué puertos hay que abrir en el firewall para un cluster MariaDB Galera?

Galera necesita 4 puertos TCP abiertos entre los nodos del cluster: 3306 para conexiones de cliente MySQL, 4567 para el tráfico de replicación del cluster, 4568 para el Incremental State Transfer (IST) y 4444 para el State Snapshot Transfer (SST), según coinciden tanto el tutorial en Dev.to como la guía extendida de eServers.

La regla de firewall recomendada permite tráfico solo entre las IPs de los propios nodos, nunca abierto a cualquier origen:

• sudo ufw allow from 10.0.0.11 to any port 3306,4567,4568,4444 proto tcp
• sudo ufw allow from 10.0.0.12 to any port 3306,4567,4568,4444 proto tcp
• sudo ufw allow from 10.0.0.13 to any port 3306,4567,4568,4444 proto tcp
• sudo ufw enable

Esta misma regla se repite en cada uno de los tres nodos, con las tres IPs. Ojo con esto: si te olvidás de habilitar el 4568 (IST), un nodo que estuvo caído poco tiempo va a forzar un SST completo en vez de una sincronización incremental, y con una base grande eso puede alargar bastante el tiempo de sincronización.

¿Cómo se configura el archivo 60-galera.cnf en cada nodo?

El archivo /etc/mysql/mariadb.conf.d/60-galera.cnf define el bloque [galera] con los parámetros wsrep, y es prácticamente idéntico en los tres nodos salvo por dos líneas: wsrep_node_address y wsrep_node_name, que cambian según la IP y el nombre de cada servidor. Para más detalles técnicos, mirá evitar recursos ociosos en el cluster.

El bloque completo, tal como lo documentan las fuentes técnicas consultadas, queda así:

• wsrep_on = ON: activa el motor de replicación wsrep en ese nodo.
• wsrep_provider = /usr/lib/galera/libgalera_smm.so: apunta a la librería Galera instalada con el paquete galera-4.
• wsrep_cluster_name = “production_cluster”: tiene que ser idéntico en los tres nodos, porque Galera no deja unirse a un nodo con nombre de cluster distinto.
• wsrep_cluster_address = “gcomm://10.0.0.11,10.0.0.12,10.0.0.13”: lista las tres IPs de los miembros. También idéntico en los tres archivos.
• binlog_format = ROW: obligatorio, Galera no funciona con binlog en formato STATEMENT.
• default_storage_engine = InnoDB: Galera certifica transacciones a nivel de fila, y eso solo lo soporta InnoDB.
• innodb_autoinc_lock_mode = 2: evita bloqueos en los autoincrementales cuando varios nodos escriben al mismo tiempo.
• wsrep_sst_method = rsync: según la documentación de MariaDB, este es también el valor por defecto del producto.
• wsrep_node_address y wsrep_node_name: únicos por servidor (IP propia y “node1”, “node2” o “node3”).

Las fuentes de eServers remarcan este punto: mantené wsrep_cluster_address exactamente igual en los tres archivos, porque esa cadena gcomm:// lista a todos los miembros del cluster.

¿Cómo se hace el bootstrap del primer nodo en Galera Cluster?

El bootstrap se ejecuta una única vez, solo en el Node 1, con el comando sudo galera_new_cluster. Esto arranca MariaDB como un cluster de un solo miembro, y se verifica corriendo sudo mysql -u root -e "SHOW STATUS LIKE 'wsrep_cluster_size';", que en ese momento tiene que devolver el valor 1.

¿Y si por error corrés galera_new_cluster en dos nodos a la vez? Exacto, terminás con dos clusters separados de un solo nodo cada uno, en vez de un cluster de tres. Por eso el bootstrap es exclusivo del primer nodo, y los otros dos arrancan con systemctl start mariadb normal, nunca con el comando de bootstrap.

¿Cómo se unen el Nodo 2 y el Nodo 3 al cluster?

El Nodo 2 y el Nodo 3 se suman ejecutando sudo systemctl start mariadb de forma normal, sin ningún comando especial. Como el wsrep_cluster_address ya apunta al Nodo 1, cada uno de estos dos servidores dispara automáticamente un State Snapshot Transfer vía rsync para copiar el dataset completo desde el nodo bootstrap. Te puede servir nuestra cobertura de aislar el tráfico en una red privada.

Volvés a chequear con SHOW STATUS LIKE 'wsrep_cluster_size'; desde cualquier nodo, y una vez que los tres están arriba, el valor tiene que ser 3. Si con dos nodos activos ese número sigue en 1 o 2, hay algo mal en el firewall o en la configuración de wsrep_cluster_address, y conviene revisar los logs de MariaDB antes de seguir sumando tráfico de producción.

¿Cómo verifico que los 3 nodos del cluster están sincronizados?

Un nodo está sano cuando tres variables de estado devuelven valores específicos: wsrep_cluster_status igual a “Primary”, wsrep_ready igual a “ON” y wsrep_local_state_comment igual a “Synced”. Estos tres chequeos aparecen documentados de forma consistente tanto en el tutorial de Dev.to como en la guía extendida de eServers.

Los tres comandos son:

• SHOW STATUS LIKE 'wsrep_cluster_status'; — debe devolver “Primary”. Si devuelve “Non-Primary”, ese nodo quedó aislado del quórum.
• SHOW STATUS LIKE 'wsrep_ready'; — debe devolver “ON”. Si está en “OFF”, el nodo rechaza cualquier query salvo SET y SHOW.
• SHOW STATUS LIKE 'wsrep_local_state_comment'; — debe devolver “Synced”. Cualquier otro valor (por ejemplo “Donor/Desynced” o “Joiner”) significa que el nodo está transfiriendo estado y todavía no conviene mandarle tráfico de lectura o escritura en producción.

Como criterio práctico, antes de meter un nodo detrás de un load balancer como HAProxy o ProxySQL, corré estos tres SHOW STATUS y confirmá los tres valores. Si alguno falla, esperá y volvé a chequear en vez de forzar tráfico sobre un nodo que todavía está sincronizando. Esto es una recomendación de sentido común operativo, no algo que hayamos probado en un entorno propio.

Variable	Valor esperado	Qué indica si falla
wsrep_cluster_status	Primary	Nodo aislado del quórum (Non-Primary)
wsrep_ready	ON	Nodo solo acepta SET/SHOW, rechaza queries normales
wsrep_local_state_comment	Synced	Nodo en transferencia de estado (Donor/Desynced, Joiner)
wsrep_cluster_size (tras join completo)	3	Falta algún nodo por unirse o hay problema de firewall/config

Errores comunes al montar un cluster Galera

• Bootstrapear más de un nodo: correr galera_new_cluster en dos servidores genera dos clusters separados de un miembro cada uno. Solo el Nodo 1 se bootstrapea; el resto arranca con systemctl start mariadb.
• Abrir el firewall antes de tener las IPs finales: si armás las reglas de UFW con IPs provisorias y después cambiás la topología, quedan puertos abiertos a servidores que ya no forman parte del cluster. Revisá las reglas cada vez que cambies IPs.
• Tablas InnoDB sin clave primaria: Galera certifica igual esas tablas si wsrep_certify_nonPK está en ON (el valor por defecto), pero eso puede generar comportamiento indefinido en ciertos escenarios, según la documentación de variables de sistema de MariaDB. Definí primary key en cada tabla InnoDB.
• Mandar tráfico a un nodo que todavía dice “Joiner” o “Donor/Desynced”: ese nodo está transfiriendo estado, no está listo para servir lecturas consistentes. Esperá a “Synced” antes de sumarlo al load balancer.
• Cluster con número par de nodos: con 2 o 4 nodos el mecanismo de quórum ante un split de red queda ambiguo. Usá siempre un número impar, 3 como mínimo.

Preguntas Frecuentes

¿Qué es MariaDB Galera Cluster y en qué se diferencia de la replicación master-slave?

MariaDB Galera Cluster es un sistema de replicación síncrona multi-maestro donde toda transacción se certifica en todos los nodos antes de confirmarse, a diferencia de la replicación master-slave asíncrona clásica, donde el maestro no espera confirmación de las réplicas y puede perder transacciones recientes en un failover.

¿Cuántos nodos mínimos necesita un cluster Galera para funcionar bien?

Tres nodos es el mínimo recomendado en producción, y siempre un número impar. Con dos nodos el mecanismo de quórum ante una partición de red no puede determinar con claridad qué mitad del cluster sigue siendo válida. Lo explicamos a fondo en visualizar el estado del cluster con otras herramientas.

¿Qué puertos necesita abrir un cluster MariaDB Galera en el firewall?

Cuatro puertos TCP entre los nodos: 3306 para conexiones de cliente MySQL, 4567 para replicación del cluster, 4568 para Incremental State Transfer (IST) y 4444 para State Snapshot Transfer (SST). Las reglas de firewall deben permitir tráfico solo entre las IPs de los propios miembros del cluster.

¿Cómo se hace el bootstrap del primer nodo en Galera Cluster?

Se ejecuta sudo galera_new_cluster exclusivamente en el nodo elegido como Node 1, y se confirma con SHOW STATUS LIKE 'wsrep_cluster_size';, que debe devolver 1 antes de sumar los demás nodos. Este comando nunca se corre en más de un servidor.

¿Cómo verifico que los 3 nodos del cluster están sincronizados?

Se corren tres consultas SQL en cada nodo: wsrep_cluster_status debe dar “Primary”, wsrep_ready debe dar “ON” y wsrep_local_state_comment debe dar “Synced”. Si algún nodo no cumple los tres valores, todavía no debería recibir tráfico de producción.

Conclusión

Levantar un cluster MariaDB Galera de 3 nodos en bare metal es un procedimiento bien documentado: instalar paquetes, configurar el bloque [galera] en cada servidor, abrir cuatro puertos entre nodos y bootstrapear una sola vez desde el Nodo 1. Lo que las fuentes dejan claro es que la parte técnica no es el punto complicado, el punto complicado es la disciplina operativa: mantener la configuración idéntica entre nodos, no bootstrapear dos veces, y no mandar tráfico a un nodo que todavía dice “Joiner” en vez de “Synced”.

Antes de poner esto en producción, corré el checklist de las tres variables wsrep en los tres nodos, aplicá los criterios de decisión de arriba para confirmar que Galera (y no un master-slave más simple) es lo que tu carga de trabajo necesita, y sumá un load balancer como HAProxy o ProxySQL delante del cluster para no depender de una sola IP de conexión. Eso sí, ninguna de las fuentes consultadas incluye benchmarks de rendimiento en carga real, así que cualquier número de throughput o latencia bajo tu propio workload específico habría que medirlo aparte.

Fuentes

• MariaDB Docs – Galera Cluster System Variables (documentación oficial)
• MariaDB Docs – wsrep_sst_method, valor por defecto y parámetros
• eServers – Guía completa de setup de MariaDB Galera Cluster en bare metal
• Dev.to – How to Set Up a 3-Node MariaDB Galera Cluster on Bare Metal