La forma de iniciar un clúster Galera de MySQL o de MariaDB, es diferente a la de un MySQL estándar o un clúster MySQL. Galera requiere de un nodo arrancado en el clúster como punto de referencia, antes de que los nodos restantes puedan unirse y formar parte del clúster. Este proceso se conoce como Bootstrap. Bootstrapping es el paso inicial para introducir un nodo de base de datos como componente principal, antes de que otros lo vean como un punto de referencia para sincronizar datos.
¿Cómo funciona?
Cuando Galera comienza con el comando de arranque en un nodo, ese nodo en particular alcanzará el estado principal (verifica el valor de wsrep_cluster_status). Los nodos restantes solo requerirán un comando de inicio normal y buscarán automáticamente el componente principal (PC) existente en el clúster y se unirán para formar un clúster. Luego, la sincronización de datos ocurre a través de una transferencia de estado incremental (IST) o una transferencia de estado de instantánea (SST) entre el que se une y el donante.
Básicamente, solo debe iniciar el clúster si deseas iniciar un nuevo clúster o cuando ningún otro nodo en el clúster está en estado PRIMARIO. Se debe tener cuidado al elegir la acción a realizar, o de lo contrario podría terminar con clústeres divididos o pérdida de datos.
¿Cómo iniciar Galera Clúster?
Los diferentes clúster Galera usan diferentes comandos de arranque (según la última versión del software). En el primer nodo, ejecuta:
# galera_new_cluster
# service mysql bootstrap
# service mysql start --wsrep-new-cluster
# mysqld_safe --wsrep-new-cluster
# galera_new_cluster
# service mysql bootstrap
# service mysql start --wsrep-new-cluster
# mysqld_safe --wsrep-new-cluster
# systemctl start mysql@bootstrap.service
# service mysql bootstrap-pxc
El comando anterior es solo un contenedor y lo que realmente hace es iniciar la instancia de MySQL en ese nodo con gcomm:// como la variable wsrep_cluster_address. También puedes definir manualmente las variables dentro de my.cnf y ejecutar el comando estándar de inicio/reinicio. Sin embargo, no olvides volver a cambiar wsrep_cluster_address para que contenga las direcciones de todos los nodos después del inicio.
Cuando un nodo principal esté activo, simplemente ejecuta el siguiente comando en los nodos posteriores:
# systemctl start mysql
# service mysql start
El nuevo nodo se conecta a los miembros del clúster según lo define el parámetro wsrep_cluster_address . Ahora recuperará automáticamente el mapa del clúster y se conectará con el resto de los nodos, formando un clúster.
Advertencia: nunca arranques cuando desees volver a conectar un nodo a un clúster existente y NUNCA ejecutes el arranque en más de un nodo a la vez.
Indicador de arranque seguro
Galera, a partir de la versión 3.19, viene con una nueva bandera llamada "safe_to_bootstrap" dentro de grastate.dat. Este indicador facilita la decisión y evita elecciones inseguras al realizar un seguimiento del orden en que se cierran los nodos. El último nodo que se apagó se marcará como "Safe-to-Bootstrap". Todos los demás nodos se marcarán como no seguros para arrancar.
Si observas el contenido de grastate.dat (el valor predeterminado es MySQL datadir):
# cat /var/lib/mysql/grastate.dat
Deberías notar el indicador en la última línea (seqno):
# GALERA saved state
version: 2.1
uuid: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno: 2575
safe_to_bootstrap: 0
Al iniciar el nuevo clúster, Galera se negará a iniciar el primer nodo que se marcó como no seguro para el inicio. Verás el siguiente mensaje en los registros:
“Puede que no sea seguro arrancar el clúster desde este nodo. No fue el último en abandonar el clúster y es posible que no contenga todas las actualizaciones.
Para forzar el arranque del clúster con este nodo, edite el archivo grastate.dat manualmente y establezca safe_to_bootstrap en 1”.
En caso de un apagado no limpio o un bloqueo total, todos los nodos tendrán "safe_to_bootstrap: 0", por lo que deberás consultar el motor de almacenamiento InnoDB para determinar qué nodo ha confirmado la última transacción en el clúster. Esto se puede lograr iniciando mysqld con la variable “–wsrep-recover” en cada uno de los nodos:
# mysqld --user=root --wsrep-recover
Lo que produce una salida como esta:
...
2022-10-06 05:43:22 36311 [Note] InnoDB: Database was not shutdown normally!
2022-10-06 05:43:22 36311 [Note] InnoDB: Starting crash recovery.
...
2022-10-06 05:43:23 36311 [Note] WSREP: Recovered position: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f:114428
...
El número después de la cadena UUID en la línea "Posición recuperada" es el que debes buscar. Elije el nodo que tenga el número más alto y edita su grastate.dat para configurar "safe_to_bootstrap: 1", como se muestra en el siguiente ejemplo:
# GALERA saved state
version: 2.1
uuid: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno: -1
safe_to_bootstrap: 1
A continuación, puedes ejecutar el comando de arranque estándar en el nodo elegido.
¿Qué pasa si los nodos han divergido?
En determinadas circunstancias, los nodos pueden haber divergido unos de otros. El estado de todos los nodos puede convertirse en No principal debido a la división de la red entre los nodos, el bloqueo del clúster o si Galera encuentra una excepción al determinar el Componente principal. A continuación, deberás seleccionar un nodo y promocionarlo para que sea un componente principal.
Para determinar qué nodo debe arrancarse, compara el valor de wsrep_last_committed en todos los nodos de la base de datos:
node1> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 10032 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+
node2> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 10348 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+
node3> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 997 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+
De los resultados anteriores, el nodo 2 tiene los datos más actualizados. En este caso, todos los nodos de Galera ya están iniciados, por lo que no es necesario que vuelva a iniciar el clúster. Solo necesitarás promover el nodo 2 para que sea un componente principal:
node2> SET GLOBAL wsrep_provider_options="pc.bootstrap=1";
Los nodos restantes se volverán a conectar al componente principal (nodo 2) y resincronizarán sus datos en función de este nodo.
Fuentes MariaDB Galera Cluster Documentation, Severalnines y Percona Product Documentation.
Recuerda, si tienes consultas sobre esta u otra cuestión relacionada con tus servidores en Clouding, no dudes en escribir a soporte@clouding.io ¡Estamos a tu lado para lo que necesites!