ApsaraDB RDS:Restore an RDS MySQL logical backup to a self-managed database

Funcionamiento

1. Descargue el archivo de copia de seguridad lógica desde la consola de RDS.

2. Descomprima el archivo .tar y posteriormente los archivos .sql.gz correspondientes a cada base de datos.

3. Cree una base de datos destino vacía e importe los archivos de esquema y datos mediante mysql.

Requisitos previos

Antes de empezar, asegúrese de contar con lo siguiente:

• Una instancia de ApsaraDB RDS for MySQL que cumpla con todos los siguientes requisitos (verifique en la página de Basic Information):

  • Versión principal: 8.0, 5.7, 5.6 o 5.5

  • Edición: High-availability Edition

  • Tipo de almacenamiento: Local SSD

• Un archivo de copia de seguridad lógica ya creado. Las copias de seguridad lógicas deben crearse manualmente, ya que el sistema genera copias de seguridad físicas de forma predeterminada. Consulte Manual backup.

• Un host Linux que ejecute la misma versión principal de MySQL que la instancia de RDS, con suficiente espacio libre en disco para almacenar los archivos de copia de seguridad descomprimidos.

Descargar el archivo de copia de seguridad

1. Vaya a la página de Instances. En la barra de navegación superior, seleccione la región donde reside su instancia de RDS y haga clic en el ID de la instancia.

2. En el panel de navegación izquierdo, haga clic en Backup and Restoration.

3. En la pestaña Base Backups > Data Backup, localice el archivo de copia de seguridad lógica que desea restaurar y haga clic en Download Instance Backup File en la columna Actions.

   Nota

   Si Download Instance Backup File no está disponible, compruebe si la edición de su instancia es compatible con backup downloads.

4. En el cuadro de diálogo Download Instance Backup File, copie la URL de descarga:

   • Si su instancia de ECS y su instancia de RDS están en la misma VPC (recomendado): copie la URL de red interna. Esta opción es más rápida y estable, especialmente para archivos de copia de seguridad grandes.

   • En caso contrario: copie la URL de descarga externa. Existe una cuota gratuita para descargas de copias de seguridad por Internet; el tráfico que exceda dicha cuota tiene costo. Consulte Billing.

5. En el host Linux, ejecute el siguiente comando para descargar el archivo de copia de seguridad. Reemplace <download_url> con la URL que copió y <custom_file_name> con el nombre que prefiera.

   Opción	Descripción
   -c	Habilita las descargas reanudables, de modo que la descarga continúa desde donde se detuvo si se interrumpe
   -O	Guarda el archivo con el nombre especificado

   wget -c '<download_url>' -O <custom_file_name>.tar

Descomprimir el archivo de copia de seguridad

1. Extraiga el archivo .tar:

   Nota

   Si aparece el mensaje This does not look like a tar archive, confirme que descargó un archivo de copia de seguridad lógica de RDS y no una copia de seguridad física. Si aparece Wrote only 512 of 10240 bytes, su disco está lleno; consulte change the instance configuration para aumentar el espacio en disco e inténtelo de nuevo.

   tar xvf <custom_file_name>.tar -C /tmp

2. Revise la estructura de directorios después de la extracción. El archivo contiene un subdirectorio por cada base de datos, cada uno con un archivo de esquema y un archivo de datos:

   tree /tmp/backup_root/   # Replace with the actual root directory created by tar.

   Salida esperada:

   /tmp/backup_root/
   ├── database1/   # Directory of target database 1
   │ ├── schema.sql # Database schema file
   │ └── data.sql   # Data file
   ├── database2/   # Directory of target database 2
   │ ├── schema.sql
   │ └── data.sql
   └── config.txt    # Backup metadata (optional)

3. Navegue al directorio de la base de datos que desea restaurar:

   cd /tmp/backup_root/<database_name>

4. Descomprima los archivos .sql.gz:

   gzip -d schema.sql.gz
   gzip -d data.sql.gz

   Esto genera los archivos schema.sql y data.sql, que importará en el siguiente paso.

Importar los datos

1. Inicie sesión en MySQL y cree una base de datos destino vacía. El usuario debe tener permiso para ejecutar todas las sentencias SQL contenidas en los archivos .sql.

   Marcador	Descripción	Ejemplo
   <user>	Nombre de usuario de MySQL	root
   <password>	Contraseña de MySQL (sin espacio después de -p)	mypassword
   <target_database_name>	Nombre para la base de datos vacía que se va a crear	restored_db

    mysql -u <user> -p<password>

    CREATE DATABASE <target_database_name>;
    EXIT;

   Reemplace los marcadores de posición de la siguiente manera:

2. Importe el esquema y luego los datos:

   Nota

   Si aparece el mensaje Can't find master key from keyring, es posible que su instancia no cumpla con los requisitos previos indicados en esta guía. Verifique la edición y el tipo de almacenamiento de la instancia de RDS.

    # Import the table schema
    mysql -u <user> -p <target_database_name> < schema.sql
   
    # Import the data
    mysql -u <user> -p <target_database_name> < data.sql

   Introduzca su contraseña cuando se le solicite después de cada comando.

Verificar la restauración

1. Inicie sesión en MySQL y confirme que las tablas y los datos estén presentes:

    mysql -u <user> -p

    USE <target_database_name>;
    SHOW TABLES;                            -- Check that tables exist
    SELECT COUNT(*) FROM <table_name>;      -- Verify the row count

   Si las tablas y los datos aparecen correctamente, la restauración ha finalizado.

Preguntas frecuentes

¿Por qué mi instancia no tiene copias de seguridad lógicas?

RDS crea copias de seguridad físicas de forma predeterminada. Para obtener una copia de seguridad lógica, debe crearla manualmente. Consulte Manual backup.

¿Por qué el valor de Restore Point in Time es 0 en las copias de seguridad lógicas?

La restauración a un momento específico requiere una copia de seguridad física combinada con una copia de seguridad de registros. Las copias de seguridad lógicas no admiten la restauración a un momento específico, por lo que el campo Restore Point in Time muestra 0.

¿Cómo soluciono el error ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty?

Este error indica que la base de datos destino ya contiene un historial de identificadores globales de transacciones (GTID). Utilice uno de los siguientes enfoques:

• Habilite GTID en la base de datos destino y vuelva a ejecutar la importación.

• Comente todas las líneas GTID_PURGED en el archivo .sql y vuelva a ejecutar la importación.

• Si no se utiliza replicación primaria/secundaria, ejecute RESET MASTER en la base de datos destino para borrar el historial de GTID y vuelva a ejecutar la importación.

¿Cómo soluciono el error ERROR 3546 (HY000): @@GLOBAL.GTID_PURGED cannot be changed: the added gtid set must not overlap with @@GLOBAL.GTID_EXECUTED?

El archivo .sql contiene información de GTID que entra en conflicto con el historial de GTID existente en la base de datos destino. Ejecute RESET MASTER para borrar el historial de GTID y vuelva a ejecutar la importación.

¿Por qué los datos restaurados solo están en la base de datos primaria y no se sincronizan con la secundaria?

El archivo .sql contiene SESSION.SQL_LOG_BIN= 0, lo cual deshabilita el registro binario durante la importación e impide que los cambios se repliquen a la base de datos secundaria. Revise el archivo de importación para verificar esta configuración.

Pasos siguientes

• Back up an ApsaraDB RDS instance — configure copias de seguridad automáticas para facilitar futuras restauraciones.

• Use mysqldump to migrate MySQL data — migre datos desde una base de datos autogestionada hacia una instancia de RDS.

• RDS MySQL mysqldump options — referencia de todas las opciones de mysqldump compatibles con ApsaraDB RDS for MySQL.