A diferencia del servidor MySQL estándar y MySQL Cluster, la forma de iniciar MySQL/MariaDB Galera Cluster es un poco diferente. Galera requiere que inicie un nodo en un clúster como punto de referencia, antes de que los nodos restantes puedan unirse y formar el clúster. Este proceso se conoce como arranque de clúster. Bootstrapping es un 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 (verifique 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 instantánea (SST) entre el que se une y el donante.
Básicamente, solo debe iniciar el clúster si desea 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, de lo contrario, podría terminar con clústeres divididos o pérdida de datos.
Los siguientes escenarios de ejemplo ilustran cuándo arrancar un clúster de tres nodos según el estado del nodo (wsrep_local_state_comment) y el estado del clúster (wsrep_cluster_status):
Estado de Galera | Flujo de arranque |
---|---|
| |
| |
| |
| |
| |
|
¿Cómo iniciar Galera Cluster?
Los 3 proveedores de Galera usan diferentes comandos de arranque (según la última versión del software). En el primer nodo, ejecute:
-
MySQL Galera Cluster (codificador):
$ service mysql bootstrap # sysvinit $ galera_new_cluster # systemd $ mysqld_safe --wsrep-new-cluster # command line
-
Clúster Percona XtraDB (Percona):
$ service mysql bootstrap-pxc # sysvinit $ systemctl start [email protected] # systemd
-
Clúster MariaDB Galera (MariaDB):
$ service mysql bootstrap # sysvinit $ service mysql start --wsrep-new-cluster # sysvinit $ galera_new_cluster # systemd $ mysqld_safe --wsrep-new-cluster # command line
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 puede definir manualmente las variables dentro de my.cnf y ejecutar el comando estándar de inicio/reinicio. Sin embargo, no olvide volver a cambiar wsrep_cluster_address para que contenga las direcciones de todos los nodos después del inicio.
Cuando el primer nodo esté activo, ejecute el siguiente comando en los nodos siguientes:
$ service mysql start
$ systemctl start mysql
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 y formará un clúster.
Advertencia:nunca arranque cuando desee volver a conectar un nodo a un clúster existente y NUNCA ejecute el arranque en más de un nodo.
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 observa el contenido de grastate.dat (el valor predeterminado es MySQL datadir), debería notar el indicador en la última línea:
# 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á el siguiente mensaje en los registros:
“Es posible 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 inicio del clúster con este nodo, edite el archivo grastate.dat manualmente y establezca safe_to_bootstrap en 1 ”.
En caso de un cierre no limpio o un bloqueo total, todos los nodos tendrán "safe_to_bootstrap:0", por lo que debemos 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, lo que produce una salida como esta:
$ mysqld --wsrep-recover
...
2016-11-18 01:42:15 36311 [Note] InnoDB: Database was not shutdown normally!
2016-11-18 01:42:15 36311 [Note] InnoDB: Starting crash recovery.
...
2016-11-18 01:42:16 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 debe buscar. Elija el nodo que tenga el número más alto y edite su grastate.dat para establecer "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, puede 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á seleccionar un nodo y promocionarlo para que sea un componente principal.
Para determinar qué nodo debe arrancarse, compare el valor de wsrep_last_committed en todos los nodos de 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 reinicie el clúster de nuevo. Solo necesitamos 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.
Si está utilizando ClusterControl (pruébelo gratis), puede determinar wsrep_last_committed y wsrep_cluster_status directamente desde ClusterControl> Overview página:O desde ClusterControl> Rendimiento> Estado de la base de datos página: