ApsaraDB RDS:Restaurer une sauvegarde logique RDS MySQL vers une base de données gérée par l'utilisateur

Fonctionnement

1. Téléchargez le fichier de sauvegarde logique depuis la console RDS.

2. Décompressez l'archive .tar puis les fichiers .sql.gz propres à chaque base de données.

3. Créez une base de données cible vide et importez les fichiers de schéma et de données avec mysql.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

• Une instance ApsaraDB RDS for MySQL répondant à tous les critères suivants (vérifiez la page Basic Information) :

  • Version majeure : 8.0, 5,7, 5,6 ou 5,5

  • Édition : High-availability Edition

  • Type de stockage : Local SSD

• Un fichier de sauvegarde logique déjà créé. Les sauvegardes logiques doivent être créées manuellement ; le système crée des sauvegardes physiques par défaut. Consultez la rubrique Sauvegarde manuelle.

• Un hôte Linux exécutant la même version majeure de MySQL que l'instance RDS, avec suffisamment d'espace disque libre pour contenir les fichiers de sauvegarde décompressés.

Télécharger le fichier de sauvegarde

1. Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où réside votre instance RDS, puis cliquez sur l'ID de l'instance.

2. Dans le volet de navigation de gauche, cliquez sur Backup and Restoration.

3. Sous l'onglet Base Backups > Data Backup, localisez le fichier de sauvegarde logique que vous souhaitez restaurer, puis cliquez sur Download Instance Backup File dans la colonne Actions.

   Remarque

   Si l'option Download Instance Backup File n'est pas disponible, vérifiez si l'édition de votre instance prend en charge les téléchargements de sauvegarde.

4. Dans la boîte de dialogue Download Instance Backup File, copiez l'URL de téléchargement :

   • Si votre instance ECS et votre instance RDS se trouvent dans le même VPC (recommandé) : copiez l'URL du réseau interne. Cette option est plus rapide et plus stable, en particulier pour les fichiers de sauvegarde volumineux.

   • Sinon : copiez l'URL de téléchargement externe. Un quota gratuit s'applique aux téléchargements de sauvegarde via Internet ; le trafic dépassant ce quota est facturé. Consultez la section Facturation.

5. Sur l'hôte Linux, exécutez la commande suivante pour télécharger le fichier de sauvegarde. Remplacez <download_url> par l'URL copiée et <custom_file_name> par un nom de votre choix.

   Option	Description
   -c	Active la reprise du téléchargement en cas d'interruption
   -O	Enregistre le fichier sous le nom spécifié

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

Décompresser le fichier de sauvegarde

1. Extrayez l'archive .tar :

   Remarque

   Si le message This does not look like a tar archive s'affiche, vérifiez que vous avez téléchargé un fichier de sauvegarde logique RDS et non une sauvegarde physique. Si le message Wrote only 512 of 10240 bytes s'affiche, votre disque est plein : modifiez la configuration de l'instance pour augmenter l'espace disque, puis réessayez.

   tar xvf <custom_file_name>.tar -C /tmp

2. Vérifiez la structure des répertoires après l'extraction. L'archive contient un sous-répertoire par base de données, chacun comprenant un fichier de schéma et un fichier de données :

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

   Sortie attendue :

   /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. Accédez au répertoire de la base de données que vous souhaitez restaurer :

   cd /tmp/backup_root/<database_name>

4. Décompressez les fichiers .sql.gz :

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

   Cette opération génère les fichiers schema.sql et data.sql, que vous importerez à l'étape suivante.

Importer les données

1. Connectez-vous à MySQL et créez une base de données cible vide. L'utilisateur doit disposer des autorisations nécessaires pour exécuter toutes les instructions SQL contenues dans les fichiers .sql.

   Espace réservé	Description	Exemple
   <user>	Nom d'utilisateur MySQL	root
   <password>	Mot de passe MySQL (sans espace après -p)	mypassword
   <target_database_name>	Nom de la base de données vide à créer	restored_db

    mysql -u <user> -p<password>

    CREATE DATABASE <target_database_name>;
    EXIT;

   Remplacez les espaces réservés comme suit :

2. Importez le schéma, puis les données :

   Remarque

   Si le message Can't find master key from keyring s'affiche, il est possible que votre instance ne réponde pas aux prérequis indiqués dans ce guide. Vérifiez l'édition et le type de stockage de l'instance 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

   Saisissez votre mot de passe lorsque vous y êtes invité après chaque commande.

Vérifier la restauration

1. Connectez-vous à MySQL et confirmez que les tables et les données sont présentes :

    mysql -u <user> -p

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

   Si les tables et les données apparaissent, la restauration est terminée.

FAQ

Pourquoi mon instance ne contient-elle aucune sauvegarde logique ?

RDS crée des sauvegardes physiques par défaut. Pour obtenir une sauvegarde logique, vous devez en créer une manuellement. Consultez la rubrique Sauvegarde manuelle.

Pourquoi la valeur Restore Point in Time est-elle égale à 0 pour les sauvegardes logiques ?

La restauration à un instant précis nécessite une sauvegarde physique combinée à une sauvegarde des journaux. Les sauvegardes logiques ne prennent pas en charge la restauration à un instant précis, c'est pourquoi le champ Restore Point in Time affiche la valeur 0.

Comment résoudre l'erreur ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty ?

Cette erreur signifie que la base de données cible contient déjà un historique des identifiants globaux de transaction (GTID). Utilisez l'une des approches suivantes :

• Activez GTID sur la base de données cible et relancez l'importation.

• Mettez en commentaire toutes les lignes GTID_PURGED dans le fichier .sql et relancez l'importation.

• Si la réplication primaire/secondaire n'est pas utilisée, exécutez RESET MASTER sur la base de données cible pour effacer l'historique GTID, puis relancez l'importation.

Comment résoudre l'erreur ERROR 3546 (HY000): @@GLOBAL.GTID_PURGED cannot be changed: the added gtid set must not overlap with @@GLOBAL.GTID_EXECUTED ?

Le fichier .sql contient des informations GTID qui entrent en conflit avec l'historique GTID existant dans la base de données cible. Exécutez RESET MASTER pour effacer l'historique GTID, puis relancez l'importation.

Pourquoi les données restaurées ne se trouvent-elles que dans la base de données principale et ne sont-elles pas synchronisées avec la base de données secondaire ?

Le fichier .sql contient SESSION.SQL_LOG_BIN= 0, ce qui désactive la journalisation binaire pendant l'importation et empêche la réplication des modifications vers la base de données secondaire. Vérifiez ce paramètre dans le fichier d'importation.

Étapes suivantes

• Sauvegarder une instance ApsaraDB RDS — configurez des sauvegardes automatiques pour faciliter les restaurations futures.

• Utiliser mysqldump pour migrer des données MySQL — migrez des données d'une base de données gérée par l'utilisateur vers une instance RDS.

• Options mysqldump RDS MySQL — référence de tous les indicateurs mysqldump pris en charge par ApsaraDB RDS for MySQL.