Restauración completa de un clúster MySQL o MariaDB Galera desde una copia de seguridad

Realizar copias de seguridad periódicas de su clúster de base de datos es imprescindible para una alta disponibilidad y recuperación ante desastres. Si por algún motivo perdiera todo el clúster y tuviera que realizar una restauración completa desde la copia de seguridad, necesitaría una copia de seguridad actualizada y confiable para comenzar.

Prácticas recomendadas para copias de seguridad

Algunas recomendaciones a tener en cuenta para un buen régimen de copias de seguridad programadas:

• Debe poder recuperarse por completo de una falla catastrófica de al menos dos copias de seguridad completas anteriores. En caso de que la copia de seguridad completa más reciente se dañe, se pierda o se corrompa,
• Su copia de seguridad debe contener al menos una copia de seguridad completa dentro de un ciclo elegido, normalmente semanal,
• Almacene las copias de seguridad lejos de la ubicación actual de los datos, preferiblemente fuera del sitio,
• Utilice una combinación de mysqldump y Xtrabackup para mayor seguridad y no confíe en un solo método,
• Pruebe la restauración de sus copias de seguridad periódicamente, p. cada dos meses.

Una copia de seguridad completa semanal combinada con una copia de seguridad incremental diaria suele ser suficiente. Mantener una cantidad de copias de seguridad durante un período de tiempo siempre es un buen plan, tal vez mantenga cada copia de seguridad semanal durante un mes. Esto le permite recuperar una base de datos más antigua en caso de emergencia o si, por algún motivo, tiene un archivo de copia de seguridad local corrupto.

mysqldump o Xtrabackup

mysqldump es muy probablemente la forma más popular de hacer una copia de seguridad de MySQL. Hace una copia de seguridad lógica de los datos, lee de cada tabla usando declaraciones SQL y luego exporta los datos a archivos de texto. Restauración de un mysqldump es tan fácil como crear el archivo de volcado. Los principales inconvenientes son que es muy lento para bases de datos grandes, no es "caliente" y elimina el grupo de búfer de InnoDB.

Xtrabackup realiza copias de seguridad activas, no bloquea la base de datos durante la copia de seguridad y, por lo general, es más rápida. Las copias de seguridad activas son importantes para la alta disponibilidad, ya que se ejecutan sin bloquear la aplicación. Este también es un factor importante cuando se usa con Galera, ya que Galera se basa en la replicación síncrona. Sin embargo, restaurar una copia de seguridad adicional puede ser un poco complicado de forma manual.

ClusterControl admite la programación de mysqldump y Xtrabackup (completa e incremental), así como la restauración de copias de seguridad directamente desde la interfaz de usuario.

Restauración completa desde la copia de seguridad

En esta publicación, le mostraremos cómo restaurar Xtrabackup (completa + incremental) en un clúster vacío que se ejecuta en MariaDB Galera Cluster. Estos pasos también deberían funcionar en Percona XtraDB Cluster o Galera Cluster for MySQL de Codership.

En nuestro clúster original, teníamos un xtrabackup completo programado diariamente, con copias de seguridad incrementales creadas cada hora. Las copias de seguridad se almacenan en ClusterControl como se muestra en la siguiente captura de pantalla:

Ahora, supongamos que hemos perdido nuestro clúster original y tenemos que realizar una restauración completa en un nuevo clúster. Los pasos incluyen:

1. Configure un nuevo servidor ClusterControl.
2. Configure un nuevo clúster de MariaDB.
3. Exporte los registros y archivos de copia de seguridad al nuevo servidor ClusterControl.
4. Inicie el proceso de restauración.
5. Inicie los nodos restantes.

El siguiente diagrama ilustra nuestra arquitectura para este ejercicio:

Paso 1:configurar un nuevo clúster de MariaDB

Instale ClusterControl e implemente un nuevo clúster de MariaDB. Vaya a ClusterControl -> Implementar -> Implementar clúster de base de datos -> MySQL Galera y especifique la información requerida en el cuadro de diálogo de implementación:

Haga clic en el botón Implementar e inicie la implementación. Dado que solo tenemos un clúster en el servidor anterior, la ID del clúster debe ser idéntica (ID del clúster:1) en esta nueva instancia.

En el antiguo servidor de ClusterControl, exporte la tabla backup_records a archivos de volcado:

$ mysqldump -uroot -p --single-transaction --no-create-info cmon backup_records > backup_records.sql

Luego, realice una copia remota de los archivos de copia de seguridad desde el servidor anterior al nuevo servidor ClusterControl:

$ scp -r /root/backups 192.168.55.150:/root/
$ scp ~/backup_records.sql 192.168.55.150:~

Lo siguiente es modificar los archivos de volcado para reflejar la nueva dirección IP del servidor ClusterControl. No olvide escapar del punto en la dirección IP:

$ sed -i "s/192\.168\.55\.170/192\.168\.55\.150/g" backup_records.sql

En el nuevo servidor ClusterControl, importe los archivos de volcado:

$ mysql -uroot -p cmon < backup_records.sql

Verifique que la lista de copias de seguridad sea correcta en el nuevo servidor de ClusterControl:

Como puede ver, todas las apariciones de la dirección IP anterior (192.168.55.170) han sido reemplazadas por la nueva dirección IP (192.168.55.150). Ahora estamos listos para realizar la restauración en el nuevo servidor.

Paso 3:Realice la restauración

Realizar la restauración a través de la interfaz de usuario de ClusterControl es un simple paso de apuntar y hacer clic. Elija qué copia de seguridad restaurar y haga clic en el botón "Restaurar". Vamos a restaurar la última copia de seguridad incremental disponible (Copia de seguridad:9). Haga clic en el botón "Restaurar" justo debajo del nombre de la copia de seguridad y aparecerá el siguiente cuadro de diálogo previo a la restauración:

Parece que el tamaño de la copia de seguridad es bastante pequeño (165,6 kB). Realmente no importa porque ClusterControl preparará todas las copias de seguridad incrementales agrupadas en el Conjunto de copia de seguridad 6, que contiene el Xtrabackup completo. También tienes varias opciones posteriores a la restauración:

• Restaurar copia de seguridad en:elija el nodo en el que restaurar la copia de seguridad.
• Tmp Dir:el directorio se usará en el servidor local de ClusterControl como almacenamiento temporal durante la preparación de la copia de seguridad. Debe ser tan grande como el directorio de datos MySQL estimado.
• Clúster de arranque desde el nodo restaurado:dado que se trata de un clúster nuevo, vamos a activarlo para que ClusterControl arranque el clúster automáticamente después de que la restauración se realice correctamente.
• Haga una copia de datadir antes de restaurar la copia de seguridad:si los datos restaurados están dañados o no como se esperaba, tendrá una copia de seguridad del directorio de datos MySQL anterior. Dado que este es un grupo nuevo, vamos a ignorar este.

La restauración de Percona Xtrabackup hará que el clúster se detenga. ClusterControl:

1. Detenga todos los nodos del clúster.
2. Restaurar la copia de seguridad en el nodo seleccionado.
3. Arranca el nodo seleccionado.

Para ver el progreso de la restauración, vaya a Actividad -> Trabajos -> Restaurar copia de seguridad y haga clic en el botón "Detalles completos del trabajo". Deberías ver algo como esto:

Una cosa importante que debe hacer es monitorear la salida del registro de errores de MySQL en el nodo de destino (192.168.55.151) durante el proceso de restauración. Después de que se complete la restauración y durante el proceso de arranque, debería ver que comienzan a aparecer las siguientes líneas:

Version: '10.1.22-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:52 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:53 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:54 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:55 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)

No entrar en pánico. Este es un comportamiento esperado porque este conjunto de copia de seguridad no almacena las credenciales de inicio de sesión de cmon de la nueva contraseña de cmon de ClusterControl. En su lugar, ha restaurado/reemplazado al antiguo usuario cmon. Lo que debe hacer es volver a otorgar al usuario cmon el servidor ejecutando la siguiente instrucción en este nodo de base de datos:

GRANT ALL PRIVILEGES ON *.* to [email protected]'192.168.55.150' IDENTIFIED BY 'mynewCMONpassw0rd' WITH GRANT OPTION;
FLUSH PRIVILEGES;

Luego, ClusterControl podría conectarse al nodo de arranque y determinar el estado del nodo y de la copia de seguridad. Si todo está bien, debería ver algo como esto:

En este punto, el nodo de destino se arranca y se ejecuta. Podemos iniciar los nodos restantes en Nodos -> elegir nodo -> Iniciar nodo y marcar la casilla de verificación "Realizar un inicio inicial":

La restauración ahora está completa y puede esperar que Rendimiento -> Crecimiento de la base de datos informe el tamaño actualizado de nuestro conjunto de datos recién restaurado:

¡Feliz restauración!