Cómo recuperar MySQL Galera Cluster de un esclavo asíncrono

Introducción

Cuando se ejecuta Galera Cluster, es una práctica común agregar uno o más esclavos asíncronos en el mismo centro de datos o en uno diferente. Esto nos proporciona un plan de contingencia con bajo RTO, y con un bajo costo operativo. En el caso de un problema irrecuperable en nuestro clúster, podemos realizar una conmutación por error rápidamente para que las aplicaciones puedan seguir teniendo acceso a los datos.

Cuando usamos este tipo de configuración, no podemos simplemente reconstruir nuestro clúster a partir de una copia de seguridad anterior. Dado que el esclavo asíncrono es ahora la nueva fuente de verdad, necesitamos reconstruir el clúster a partir de él.

Esto no significa que solo tengamos una forma de hacerlo, ¡tal vez haya una mejor! Siéntete libre de darnos tus sugerencias en la sección de comentarios al final de esta publicación.

Topología

Arriba, podemos ver una topología de muestra con Galera Cluster y una réplica/esclavo asíncrono.

A continuación veremos como podemos recrear nuestro cluster, partiendo del esclavo, en el caso de encontrarnos con algo como esto:

Si miramos la imagen anterior, podemos ver que nuestros 3 nodos de Galera están caídos. Nuestro esclavo no puede conectarse al maestro de Galera, pero está en un estado "En funcionamiento".

Promocionar esclavo

Como nuestro esclavo funciona correctamente, podemos promoverlo a maestro y apuntar nuestras aplicaciones hacia él. Para ello, debemos deshabilitar el parámetro de solo lectura en nuestro esclavo y restablecer la configuración del esclavo.

En nuestro esclavo (mysql1):

mysql> SET GLOBAL read_only=0;
Query OK, 0 rows affected (0.00 sec)
mysql> STOP SLAVE;
Query OK, 0 rows affected (0.00 sec)
mysql> RESET SLAVE;
Query OK, 0 rows affected (0.18 sec)

Crear nuevo clúster

A continuación, para iniciar la recuperación de nuestro clúster fallido, crearemos un nuevo clúster de Galera. Esto se puede hacer fácilmente a través de ClusterControl ClusterControl, desplácese más abajo en este blog para ver cómo.

Una vez que hayamos implementado nuestro nuevo clúster de Galera, tendríamos algo como lo siguiente:

Replicación

Debemos asegurarnos de que tenemos configurados los parámetros de replicación.

Para los nodos Galera (galera1, galera2, galera3):

server_id=<ID>         # Different value in each node
binlog_format=ROW
log_bin = /var/lib/mysql-binlog/binlog
log_slave_updates = ON
gtid_mode = ON
enforce_gtid_consistency = true
relay_log = relay-bin
expire_logs_days = 7

Para el nodo maestro (mysql1):

server_id=<ID>         # Different value in each node
binlog_format=ROW
log_bin=binlog
log_slave_updates=1
gtid_mode=ON
enforce_gtid_consistency=1
relay_log=relay-bin
expire_logs_days=7
read_only=ON
sync_binlog=1
report_host=<HOSTNAME or IP>    # Local server

Para que nuestro nuevo esclavo (galera1) se conecte con nuestro nuevo maestro (mysql1), debemos crear un usuario con permisos de replicación en nuestro maestro.

En nuestro nuevo maestro (mysql1):

mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password';

Nota:Podemos reemplazar el "%" con la IP del nodo Galera Cluster que será nuestro esclavo, en nuestro ejemplo, galera1.

Copia de seguridad

Si no lo tenemos, debemos crear una copia de seguridad consistente de nuestro maestro (mysql1) y cargarlo en nuestro nuevo Galera Cluster. Para ello podemos utilizar la herramienta XtraBackup o mysqldump. Veamos ambas opciones.

En nuestro ejemplo, usamos la base de datos sakila disponible para realizar pruebas.

Herramienta XtraBackup

Generamos la copia de seguridad en el nuevo maestro (mysql1). En nuestro caso lo enviamos al directorio local /root/backup:

$ innobackupex /root/backup/

Debemos recibir el mensaje:

180705 22:08:14 completed OK!

Comprimimos la copia de seguridad y la enviamos al nodo que será nuestro esclavo (galera1):

$ cd /root/backup
$ tar zcvf 2018-07-05_22-08-07.tar.gz 2018-07-05_22-08-07
$ scp /root/backup/2018-07-05_22-08-07.tar.gz galera1:/root/backup/

En galera1, extraiga la copia de seguridad:

$ tar zxvf /root/backup/2018-07-05_22-08-07.tar.gz

Detenemos el clúster (si está iniciado). Para ello detenemos los servicios mysql de los 3 nodos:

$ service mysql stop

En galera1, renombramos el directorio de datos de mysql y cargamos la copia de seguridad:

$ mv /var/lib/mysql /var/lib/mysql.bak
$ innobackupex --copy-back /root/backup/2018-07-05_22-08-07

Debemos recibir el mensaje:

180705 23:00:01 completed OK!

Asignamos los permisos correctos en el directorio de datos:

$ chown -R mysql.mysql /var/lib/mysql

Luego debemos inicializar el clúster.

Una vez inicializado el primer nodo, debemos iniciar el servicio MySQL para los nodos restantes, eliminando cualquier copia anterior del archivo grastate.dat, y luego verificar que nuestros datos estén actualizados.

$ rm /var/lib/mysql/grastate.dat
$ service mysql start

Nota:Verifique que el usuario utilizado por XtraBackup se cree en nuestro nodo inicializado y sea el mismo en cada nodo.

mysqldump

En general, no recomendamos hacerlo con mysqldump, porque puede ser bastante lento con un gran volumen de datos. Pero es una alternativa para realizar la tarea.

Generamos la copia de seguridad en el nuevo maestro (mysql1):

$ mysqldump -uroot -p --single-transaction --skip-add-locks --triggers --routines --events --databases sakila > /root/backup/sakila_dump.sql

Lo comprimimos y lo enviamos a nuestro nodo esclavo (galera1):

$ gzip /root/backup/sakila_dump.sql
$ scp /root/backup/sakila_dump.sql.gz galera1:/root/backup/

Cargamos el volcado en galera1.

$ gunzip /root/backup/sakila_dump.sql.gz
$ mysql -p < /root/backup/sakila_dump.sql

Cuando se cargue el volcado en galera1, debemos reiniciar el servicio MySQL en los nodos restantes, eliminando el archivo grastate.dat, y verificar que tenemos nuestros datos actualizados.

$ rm /var/lib/mysql/grastate.dat
$ service mysql start

Iniciar esclavo de replicación

Independientemente de la opción que elijamos, XtraBackup o mysqldump, si todo salió bien, en este paso ya podemos activar la replicación en el nodo que será nuestro esclavo (galera1).

$ mysql> CHANGE MASTER TO MASTER_HOST = 'mysql1', MASTER_PORT = 3306, MASTER_USER = 'slave_user', MASTER_PASSWORD = 'slave_password', MASTER_AUTO_POSITION = 1;
$ mysql> START SLAVE;

Verificamos que el esclavo esté funcionando:

mysql> SHOW SLAVE STATUS\G
       Slave_IO_Running: Yes
       Slave_SQL_Running: Yes

En este punto, tenemos algo como lo siguiente:

Después de que NewGalera1 esté actualizado, podemos volver a apuntar la aplicación a nuestro nuevo clúster de galera y volver a configurar la replicación asíncrona.

Control de clúster

Como mencionamos anteriormente, con ClusterControl podemos hacer varias de las tareas mencionadas anteriormente en unos pocos clics. También cuenta con opciones de recuperación automática, tanto para los nodos como para el clúster. Veamos algunas tareas con las que puede ayudar.

Para realizar una implementación, simplemente seleccione la opción "Implementar clúster de base de datos" y siga las instrucciones que aparecen.

Podemos elegir entre diferentes tipos de tecnologías y proveedores. Debemos especificar Usuario, Clave o Contraseña y puerto para conectarnos por SSH a nuestros servidores. También necesitamos el nombre de nuestro nuevo clúster y si queremos que ClusterControl instale el software y las configuraciones correspondientes por nosotros.

Después de configurar la información de acceso SSH, debemos definir los nodos en nuestro clúster. También podemos especificar qué repositorio usar. Necesitamos agregar nuestros servidores al clúster que vamos a crear.

Podemos monitorear el estado de la creación de nuestro nuevo clúster desde el monitor de actividad de ClusterControl.

Además, podemos hacer una importación de nuestro clúster o base de datos actual siguiendo los mismos pasos. En este caso, ClusterControl no instalará el software de la base de datos porque ya hay una base de datos ejecutándose.

Para agregar un esclavo de replicación, debe hacer clic en Acciones de clúster, seleccionar Agregar esclavo de replicación y agregar la información de acceso SSH del nuevo servidor. ClusterControl se conectará al servidor para realizar las configuraciones necesarias para esta acción.

Para convertir uno o más nodos de Galera en servidores maestros (en el sentido de producir binlogs), puede ir a Acciones de nodo y seleccionar Habilitar registro binario.

Las copias de seguridad se pueden configurar con XtraBackup (completa o incremental) y mysqldump, y tiene otras opciones como cargar la copia de seguridad en la nube, encriptación, compresión, programación y más.

Para restaurar la copia de seguridad, vaya a la pestaña Copia de seguridad y elija la opción Restaurar, luego seleccione en qué servidor desea restaurar.

Si tiene un esclavo y desea cambiar el maestro o reconstruir la replicación, puede ir a Acciones de nodo y seleccionar la opción.

Conclusión

Como pudimos ver, tenemos varias formas de lograr nuestro objetivo, algunas más complejas, otras más fáciles de usar, pero con cualquiera de ellas puedes recrear un clúster a partir de un esclavo asíncrono. Xtrabackup restauraría más rápido para volúmenes de datos más grandes. Para protegerse contra el error del operador (por ejemplo, una DROP TABLE errónea), también podría usar un esclavo retrasado para tener tiempo de detener la propagación de la instrucción.

Esperamos que esta información sea útil y que nunca tengas que usarla en producción;)