Mysqldump es la herramienta de copia de seguridad lógica más popular para MySQL. Está incluido en la distribución de MySQL, por lo que está listo para usarse en todas las instancias de MySQL.
Las copias de seguridad lógicas no son, sin embargo, la forma más rápida ni la que ocupa menos espacio para realizar copias de seguridad de bases de datos MySQL, pero tienen una gran ventaja sobre las copias de seguridad físicas.
Las copias de seguridad físicas suelen ser copias de seguridad de todo o nada. Si bien es posible crear una copia de seguridad parcial con Xtrabackup (lo describimos en una de nuestras publicaciones de blog anteriores), restaurar dicha copia de seguridad es complicado y lleva mucho tiempo.
Básicamente, si queremos restaurar una sola tabla, debemos detener toda la cadena de replicación y realizar la recuperación en todos los nodos a la vez. Este es un problema importante:en estos días, rara vez puede permitirse el lujo de detener todas las bases de datos.
Otro problema es que el nivel de la tabla es el nivel de granularidad más bajo que puede lograr con Xtrabackup:puede restaurar una sola tabla pero no puede restaurar parte de ella. Sin embargo, la copia de seguridad lógica se puede restaurar en la forma de ejecutar declaraciones SQL, por lo tanto, se puede realizar fácilmente en un clúster en ejecución y puede (no lo llamaríamos fácilmente, pero aún así) elegir qué declaraciones SQL ejecutar para que pueda hacer una restauración parcial de una tabla.
Veamos cómo se puede hacer esto en el mundo real.
Restauración de una sola tabla MySQL usando mysqldump
Al principio, tenga en cuenta que las copias de seguridad parciales no proporcionan una vista uniforme de los datos. Cuando realiza copias de seguridad de tablas separadas, no puede restaurar dicha copia de seguridad en una posición conocida en el tiempo (por ejemplo, para aprovisionar el esclavo de replicación), incluso si restaurara todos los datos de la copia de seguridad. Habiendo dejado esto atrás, procedamos.
Tenemos un maestro y un esclavo:
El conjunto de datos contiene un esquema y varias tablas:
mysql> SHOW SCHEMAS;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sbtest |
| sys |
+--------------------+
5 rows in set (0.01 sec)
mysql> SHOW TABLES FROM sbtest;
+------------------+
| Tables_in_sbtest |
+------------------+
| sbtest1 |
| sbtest10 |
| sbtest11 |
| sbtest12 |
| sbtest13 |
| sbtest14 |
| sbtest15 |
| sbtest16 |
| sbtest17 |
| sbtest18 |
| sbtest19 |
| sbtest2 |
| sbtest20 |
| sbtest21 |
| sbtest22 |
| sbtest23 |
| sbtest24 |
| sbtest25 |
| sbtest26 |
| sbtest27 |
| sbtest28 |
| sbtest29 |
| sbtest3 |
| sbtest30 |
| sbtest31 |
| sbtest32 |
| sbtest4 |
| sbtest5 |
| sbtest6 |
| sbtest7 |
| sbtest8 |
| sbtest9 |
+------------------+
32 rows in set (0.00 sec)Ahora, tenemos que hacer una copia de seguridad. Hay varias formas en las que podemos abordar este tema. Podemos realizar una copia de seguridad coherente de todo el conjunto de datos, pero esto generará un único archivo grande con todos los datos. Para restaurar la tabla única, tendríamos que extraer los datos de la tabla de ese archivo. Por supuesto que es posible, pero lleva mucho tiempo y es una operación bastante manual que puede programarse, pero si no tiene los scripts adecuados, escribir código ad hoc cuando su base de datos está inactiva y está bajo una gran presión es no necesariamente la idea más segura.
En lugar de eso, podemos preparar una copia de seguridad de manera que cada tabla se almacene en un archivo separado:
[email protected]:~/backup# d=$(date +%Y%m%d) ; db='sbtest'; for tab in $(mysql -uroot -ppass -h127.0.0.1 -e "SHOW TABLES FROM ${db}" | grep -v Tables_in_${db}) ; do mysqldump --set-gtid-purged=OFF --routines --events --triggers ${db} ${tab} > ${d}_${db}.${tab}.sql ; doneTenga en cuenta que configuramos --set-gtid-purged=OFF. Lo necesitamos si vamos a cargar estos datos más adelante en la base de datos. De lo contrario, MySQL intentará configurar @@GLOBAL.GTID_PURGED, lo que probablemente fallará. MySQL también establecería SET @@SESSION.SQL_LOG_BIN=0; que definitivamente no es lo que queremos. Esas configuraciones son necesarias si queremos hacer una copia de seguridad consistente de todo el conjunto de datos y nos gustaría usarla para aprovisionar un nuevo nodo. En nuestro caso, sabemos que no es una copia de seguridad coherente y no hay forma de que podamos reconstruir nada a partir de ella. Todo lo que queremos es generar un volcado que podamos cargar en el maestro y dejar que se replique en los esclavos.
Ese comando generó una buena lista de archivos sql que se pueden cargar en el clúster de producción:
[email protected]:~/backup# ls -alh
total 605M
drwxr-xr-x 2 root root 4.0K Mar 18 14:10 .
drwx------ 9 root root 4.0K Mar 18 14:08 ..
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest10.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest11.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest12.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest13.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest14.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest15.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest16.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest17.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest18.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest19.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest1.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest20.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest21.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest22.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest23.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest24.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest25.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest26.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest27.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest28.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest29.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest2.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest30.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest31.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest32.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest3.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest4.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest5.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest6.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest7.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest8.sql
-rw-r--r-- 1 root root 19M Mar 18 14:10 20200318_sbtest.sbtest9.sqlCuando desee restaurar los datos, todo lo que necesita hacer es cargar el archivo SQL en el nodo maestro:
[email protected]:~/backup# mysql -uroot -ppass sbtest < 20200318_sbtest.sbtest11.sqlLos datos se cargarán en la base de datos y se replicarán en todos los esclavos.
¿Cómo restaurar una sola tabla MySQL usando ClusterControl?
Actualmente, ClusterControl no proporciona una manera fácil de restaurar solo una tabla, pero aún es posible hacerlo con solo unas pocas acciones manuales. Hay dos opciones que puede utilizar. Primero, adecuado para una pequeña cantidad de tablas, básicamente puede crear un programa en el que realice copias de seguridad parciales de tablas separadas una por una:
Aquí, estamos realizando una copia de seguridad de la tabla sbtest.sbtest1. Podemos programar fácilmente otra copia de seguridad para la tabla sbtest2:
Como alternativa, podemos realizar una copia de seguridad y colocar los datos de un único esquema en un archivo separado:
Ahora puede encontrar los datos que faltan a mano en el archivo, restaurar esta copia de seguridad en un servidor separado o deja que ClusterControl lo haga:
Usted mantiene el servidor en funcionamiento y puede extraer los datos que quería restaurar usando mysqldump o SELECT... INTO OUTFILE. Dichos datos extraídos estarán listos para ser aplicados en el clúster de producción.
