Backup lógico y restauración de MySQL (mysqldump, MySQL Shell)

Backup lógico y restauración con mysqldump o MySQL Shell (util.dumpInstance / dumpSchemas / dumpTables + util.loadDump): una tabla, un esquema o toda la instancia; solo estructura o solo datos; migración a otro servidor; extracción de una sola tabla de un dump completo; backup programado con systemd/cron, sin contraseña mediante login-path, verificado y con retención. Cada variante termina con una comparación del número de filas. Use esta guía para migraciones, recuperación de objetos sueltos y cambios de versión; para el backup diario de bases de datos grandes, restauraciones rápidas y la recuperación a un momento dado (PITR), use la guía de Percona XtraBackup.

Topología: 1 servidor (+ un servidor de destino en la migración y en la restauración de la instancia)

Escenarios

• Export / import de tablas — Hacer un backup de una o varias tablas, copiarlas a otro esquema/servidor o restaurarlas. El origen sigue en servicio; en las tablas InnoDB no se toman locks.
• Backup / restauración de un esquema (base de datos) — Hacer un backup de una base de datos (esquema) completa o cargarla en otro esquema/servidor. El origen sigue en servicio; en el destino, las tablas con el mismo nombre se eliminan y se vuelven a crear.
• Instancia completa (usuarios + todos los esquemas) — El backup se hace en este servidor y la restauración en un servidor vacío: usuarios, privilegios y todos los esquemas. Para reconstruir un servidor o cambiar de versión/plataforma.
• Solo estructura (DDL) — Definiciones de tablas, vistas, triggers, procedimientos y eventos; sin datos. Para comparar esquemas, montar un entorno vacío o poner la estructura bajo control de versiones.
• Solo datos — Solo se transfieren las filas, con la estructura ya creada en el destino (p. ej. para refrescar datos de prueba). Los triggers del destino pueden dispararse durante la carga; la guía lo comprueba.
• Migración a otro servidor — Se trabaja en el servidor de destino y se conecta al origen por la red con un login-path. En el momento del corte la aplicación deja de escribir; la interrupción dura lo que el dump + la carga. Para cambiar de servidor, de sistema operativo o de versión.
• Extraer una sola tabla de un dump completo — Tiene un dump completo y solo necesita una tabla (filas borradas, tabla eliminada con DROP). Se extrae a un esquema aparte sin tocar el esquema original, o se vuelve a colocar la tabla eliminada.
• Backup programado (systemd timer / cron) — Backup lógico automático todos los días a una hora fija: usuario de backup propio, login-path, script, systemd timer o cron, período de retención y aviso de errores. El origen sigue en servicio.

Antes de empezar

• MySQL … está en ejecución; el usuario root del sistema operativo puede conectarse sin contraseña con el comando mysql (auth_socket o ~/.mylogin.cnf). Si se instaló con la guía DBAtlas Instalación de MySQL en un solo servidor, las rutas son las mismas.
• Se conoce el tamaño de los esquemas y el directorio de backup … tiene espacio libre suficiente (un backup lógico comprimido suele ocupar el 10–30 % del volumen de datos; los índices solo entran en el dump como definiciones).
• Todas las tablas son InnoDB. --single-transaction (y el dump consistente de MySQL Shell) solo es consistente y sin locks para las tablas InnoDB; si hay una tabla MyISAM, las escrituras en ella durante el dump generan inconsistencias.
• El servidor en el que se instalará MySQL Shell tiene acceso al repositorio de MySQL (repo.mysql.com) o hay un mirror interno configurado.
• En el servidor de destino … está instalada (con la guía de instalación de DBAtlas) y en ejecución la misma versión de MySQL o una más reciente, y no contiene esquemas de usuario. No se admite cargar en una versión anterior, como de 8.4 a 8.0 para volver atrás.
• El servidor de destino tiene acceso al puerto … del origen.
• El servidor puede enviar correo: el MTA local (postfix) reenvía al relay SMTP corporativo.
• Hay una ventana de mantenimiento planificada para una restauración o migración grande; si se va a sobrescribir el destino, se ha hecho un backup del destino.
• Este servidor es una réplica sana: los threads IO y SQL están en Yes y el retraso es bajo. La posición del binlog en el dump (--source-data=2) se refiere al binlog propio de esta réplica; si se va a usar para PITR, log_replica_updates debe estar habilitado (es el valor por defecto en 8.x).
• Este servidor es miembro de un InnoDB Cluster y ahora está SECONDARY / ONLINE.

Fases de la guía

• Preparación — Crear el directorio de backup · Comprobar los motores de las tablas y las transacciones largas · Instalar MySQL Shell
• Restauración (import) — Crear el esquema de destino · Crear la estructura de las tablas en el destino · Comprobar los triggers del destino · Cargar (mysql) · Cargar (mysql, sobre el mismo esquema) · Cargar (util.loadDump) …
• Backup de la instancia — Exportar los usuarios y los privilegios · Hacer un backup de todos los esquemas (mysqldump) · Hacer un backup de la instancia (util.dumpInstance) · Copiar el backup al servidor de restauración · Cargar el backup (mysql) · Cargar los usuarios …
• Cuenta de migración en el servidor de origen — Crear el usuario de migración · Abrir el puerto hacia el destino en el firewall · Detener la aplicación (corte)
• Transferencia en el servidor de destino — Guardar la conexión al origen como login-path · Migrar los usuarios · Transferir los esquemas (mysqldump | mysql) · Cargar los usuarios en el destino · Hacer el dump del origen (util.dumpInstance / dumpSchemas) · Cargar en el destino (util.loadDump) …
• Extraer una sola tabla de un dump — Comprobar que la tabla está en el dump · Extraer la tabla del dump · Crear el esquema de destino · Cargar la tabla · Restaurar la tabla en el esquema original · Comparar el número de filas …
• Usuario de backup y login-path — Crear el usuario de backup del sistema operativo · Crear la cuenta de backup de MySQL · Guardar el login-path (mysql_config_editor)
• Script de backup — Instalar la herramienta de avisos · Escribir el script de backup · Hacer ejecutable el script · Hacer el primer backup a mano
• Programación (systemd timer) — Escribir el servicio de systemd · Escribir el systemd timer · Habilitar el timer y lanzar el servicio a mano · Comprobar que se ejecutó la tarea programada (al día siguiente)
• Programación (cron) — Preparar el servicio cron · Escribir la tarea de cron · Ajustar los permisos del archivo de cron y probar en un entorno de cron · Comprobar que se ejecutó la tarea programada (al día siguiente)
• Verificación y monitorización — Restaurar el último backup en un esquema de prueba · Vigilar la antigüedad del último backup
• Siguiente paso: backup físico — Cubrir las limitaciones del backup lógico