ApsaraDB RDS:Restaurer les données d'une instance ApsaraDB RDS for MySQL vers une base de données MySQL auto-gérée à partir d'un fichier de sauvegarde physique

Fonctionnement

1. Téléchargez un fichier de sauvegarde physique depuis la console ApsaraDB RDS.

2. Décompressez le fichier à l'aide de qpress et xbstream.

3. Exécutez Percona XtraBackup pour restaurer les données dans un nouveau répertoire de données sur l'hôte MySQL auto-géré.

4. Démarrez le processus MySQL auto-géré en utilisant le répertoire de données restauré.

5. Connectez-vous à la base de données et vérifiez les données.

Limitations

• Disques locaux uniquement. Les fichiers de sauvegarde physique sont disponibles uniquement pour les instances RDS utilisant des Premium Local SSDs. Si votre instance utilise des disques cloud, consultez Restaurer les données d'une instance ApsaraDB RDS for MySQL vers une instance MySQL auto-gérée à l'aide de fichiers de sauvegarde instantanés.

• Restauration complète uniquement. Cette procédure restaure l'intégralité de la sauvegarde. Pour restaurer des bases de données ou des tables spécifiques, consultez Restaurer les données d'une instance ApsaraDB RDS for MySQL depuis un fichier de sauvegarde logique vers une instance MySQL auto-gérée.

• Linux uniquement. La cible de restauration doit être une base de données MySQL exécutée sous Linux.

• Pas de TDE. Les tables chiffrées avec Transparent Data Encryption (TDE) ne peuvent pas être restaurées via cette procédure. Déchiffrez toutes les tables avant de télécharger le fichier de sauvegarde. Pour vérifier, accédez à Data Security > TDE sur la page des détails de l'instance.

• Pas de clusters MGR. Cette procédure ne prend pas en charge les clusters RDS utilisant le mode de réplication de groupe MySQL (MGR).

Prérequis

Avant de commencer, assurez-vous que :

• Votre instance RDS exécute MySQL 8.0, 5,7, 5,6 ou 5,5 sur RDS High-availability Edition avec des Premium Local SSDs. Vérifiez ces informations sur la page Basic Information de l'instance.

• Aucune table de l'instance n'est chiffrée avec TDE.

• L'utilisateur RAM que vous utilisez dispose des autorisations nécessaires pour télécharger les fichiers de sauvegarde. Pour plus de détails, consultez Autoriser un utilisateur RAM avec des autorisations en lecture seule à télécharger des fichiers de sauvegarde.

• La base de données MySQL auto-gérée exécute la même version majeure que votre instance RDS (par exemple, les deux exécutent MySQL 8.0).

• La base de données MySQL auto-gérée s'exécute sous Linux. Les exemples de cette rubrique utilisent CentOS 7.9 64 bits.

Impacts potentiels

• Si d'autres services sont en cours d'exécution dans la base de données MySQL auto-gérée, ils deviennent indisponibles pendant la restauration.

• La restauration écrit les données dans un nouveau répertoire de données et n'affecte pas les données existantes de la base de données auto-gérée.

Facturation

• Les sauvegardes manuelles consomment de l'espace de stockage de sauvegarde. Le stockage excédentaire au-delà du quota gratuit est facturé. Consultez Éléments facturables et tarification pour le stockage de sauvegarde d'une instance ApsaraDB RDS for MySQL.

• Le téléchargement via Internet génère des frais de trafic si le trafic dépasse le quota gratuit. Pour éviter ces frais, téléchargez le fichier de sauvegarde à l'aide d'une URL interne lorsque l'hôte MySQL auto-géré et l'instance RDS se trouvent dans la même région et le même VPC. Consultez Frais de téléchargement.

Préparer l'environnement

sudo mkdir /var/mysql_bkdata
sudo chown -R $USER:$USER /var/mysql_bkdata

sudo mkdir /var/mysql_newdata
sudo chown -R $USER:$USER /var/mysql_newdata

sudo find / -name my.cnf

wget https://downloads.percona.com/downloads/Percona-XtraBackup-2.4/Percona-XtraBackup-2.4.28/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.28-1.el7.x86_64.rpm
sudo yum localinstall -y percona-xtrabackup-24-2.4.28-1.el7.x86_64.rpm

# Download the qpress executable
wget "https://help-static-aliyun-doc.aliyuncs.com/file-manage-files/zh-CN/20230406/flxd/qpress-11-linux-x64.tar"

# Extract the archive
tar -xvf qpress-11-linux-x64.tar

# Grant execute permissions
sudo chmod 775 qpress

# Make qpress available system-wide
sudo cp qpress /usr/bin

Étape 1 : Télécharger le fichier de sauvegarde

1. Connectez-vous à la console ApsaraDB RDS. 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. Choisissez Base Backups > Data Backup. Recherchez le fichier de sauvegarde physique à télécharger et cliquez sur Download Instance Backup dans la colonne Actions.

   • Si aucun fichier de sauvegarde physique n'est disponible, créez-en un d'abord. Consultez Effectuer une sauvegarde manuelle d'une instance ApsaraDB RDS for MySQL.

   • Si la page Advanced Download s'affiche, votre instance utilise des disques cloud et cette procédure ne s'applique pas. Consultez plutôt Restaurer à l'aide de fichiers de sauvegarde instantanés.

4. Dans la boîte de dialogue Download Instance Backup Set, cliquez sur Copy Internal URL ou Copy Public URL.

   Important

   - Internal URL : L'hôte MySQL auto-géré et l'instance RDS doivent se trouver dans le même VPC. Les VPC inter-régions et les configurations réseau classique vers VPC ne sont pas pris en charge. - Public URL : Des frais de trafic Internet s'appliquent si vous dépassez le quota gratuit. - Une URL de téléchargement est valide pendant 1 heure après sa génération. Actualisez la page pour obtenir une nouvelle URL si elle expire.

5. Sur l'hôte Linux, exécutez la commande suivante pour télécharger le fichier de sauvegarde. Remplacez l'URL par celle que vous avez copiée.

   - Entourez l'URL de guillemets simples afin que le shell la traite comme une chaîne littérale. - Remplacez test_xb.qp par le nom de fichier de votre choix, mais conservez la même extension que dans l'URL de téléchargement . - Extensions des fichiers de sauvegarde physique : _xb.qp ou _qp.xb pour MySQL 8.0/5,7/5,6 ; tar.gz pour MySQL 5.5. - Ne modifiez ni ne supprimez un fichier de sauvegarde physique. Si vous devez modifier les données, restaurez-les d'abord dans la base de données auto-gérée.

   wget -c 'https://****.bak.rds.aliyuncs.com/****_xb.qp?****' -O test_xb.qp

Étape 2 : Décompresser le fichier de sauvegarde

Exécutez la commande de décompression correspondant à l'extension de votre fichier de sauvegarde. Remplacez le nom de fichier et le répertoire par vos valeurs réelles.

Fichiers _xb.qp

# MySQL 8.0
qpress -do test_xb.qp | /u01/xtrabackup80/bin/xbstream -x -v -C /var/mysql_bkdata/

# MySQL 5.5 / 5.6 / 5.7
qpress -do test_xb.qp | xbstream -x -v -C /var/mysql_bkdata/

Fichiers _qp.xb

# Step 1: Parse the file
cat test_qp.xb | xbstream -x -v -C /var/mysql_bkdata/

# Step 2: Decompress
## MySQL 5.5 / 5.6 / 5.7
innobackupex --decompress --remove-original /var/mysql_bkdata/

## MySQL 8.0
/u01/xtrabackup80/bin/xtrabackup --decompress --remove-original --target-dir=/var/mysql_bkdata/

Fichiers .tar.gz

tar -izxvf test.tar.gz -C /var/mysql_bkdata/

Fichiers .xb.gz

# MySQL 8.0
gzip -d -c test.xb.gz | /u01/xtrabackup80/bin/xbstream -x -v -C /var/mysql_bkdata/

# MySQL 5.5 / 5.6 / 5.7
gzip -d -c test.xb.gz | xbstream -x -v -C /var/mysql_bkdata/

Étape 3 : Restaurer les données

Avant la restauration, arrêtez la base de données MySQL auto-gérée. Vérifiez la présence de processus MySQL en cours d'exécution et terminez-les :

ps -ef | grep '[m]ysql'
sudo kill -9 <PID>

Suivez les étapes correspondant à votre version de MySQL.

/u01/xtrabackup80/bin/xtrabackup --defaults-file=/var/mysql_bkdata/backup-my.cnf \
  --prepare --target-dir=/var/mysql_bkdata/

sudo vim /etc/my.cnf

datadir = /var/mysql_newdata

chown -R mysql:mysql /var/mysql_newdata

sudo xtrabackup --defaults-file=/etc/my.cnf --copy-back --target-dir=/var/mysql_bkdata/

innobackupex --defaults-file=/var/mysql_bkdata/backup-my.cnf --apply-log /var/mysql_bkdata/

sudo vim /etc/my.cnf

datadir = /var/mysql_newdata
innodb_undo_tablespaces=2
innodb_undo_directory=/var/mysql_newdata

cat /var/mysql_bkdata/backup-my.cnf | grep innodb_undo_tablespaces

sudo innobackupex --defaults-file=/etc/my.cnf --copy-back /var/mysql_bkdata/

innobackupex --defaults-file=/var/mysql_bkdata/backup-my.cnf --apply-log /var/mysql_bkdata/

sudo vim /usr/my.cnf

datadir = /var/mysql_newdata

sudo innobackupex --defaults-file=/usr/my.cnf --copy-back /var/mysql_bkdata/

innobackupex --defaults-file=/var/mysql_bkdata/backup-my.cnf --apply-log /var/mysql_bkdata/

sudo vim /etc/my.cnf

datadir = /var/mysql_newdata
innodb_log_file_size=1048576000

cat /var/mysql_bkdata/backup-my.cnf | grep innodb_log_file_size

sudo innobackupex --defaults-file=/etc/my.cnf --copy-back /var/mysql_bkdata/

sudo rm -rf /var/mysql_newdata/*

Étape 4 : Démarrer la base de données

apt install -y apparmor-utils
aa-complain /usr/sbin/mysqld

USE mysql;
ALTER TABLE proc ENGINE=myisam;
ALTER TABLE event ENGINE=myisam;
ALTER TABLE func ENGINE=myisam;

SET SQL_MODE='ALLOW_INVALID_DATES';

getenforce

Étape 5 : Vérifier la restauration

1. Connectez-vous à la base de données MySQL auto-gérée :

   Si vous avez oublié les identifiants, ajoutez --skip-grant-tables à la commande de démarrage (étape 4) pour contourner la vérification des autorisations. Réinitialisez les identifiants après la connexion.

   mysql -u<username> -p<password>

2. Vérifiez que les bases de données attendues sont présentes :

   SHOW DATABASES;

   Si vous ne voyez que des bases de données système ou un sous-ensemble de bases de données, redémarrez la base de données auto-gérée et reconnectez-vous en utilisant le compte root ou le compte privilégié de l'instance RDS d'origine.

3. Si les horodatages des données sont dans le mauvais fuseau horaire, définissez time_zone sur la base de données auto-gérée pour qu'elle corresponde à l'instance RDS. Si le paramètre time_zone de RDS est défini sur system, recherchez la région de l'instance RDS et utilisez le fuseau horaire correspondant.

Résolution des erreurs de connexion :

Erreur : Access denied for user 'XXX'

Vérifiez si le nom d'utilisateur et le mot de passe du compte utilisé pour se connecter à la base de données sont corrects. Le compte doit avoir été créé sur l'instance RDS.

Mot de passe après la restauration :

• MySQL 5.7 ou 8,0 : Le mot de passe root est identique à celui de l'instance RDS.

• MySQL 5.5 ou 5,6 : Réinitialisez le mot de passe root. Consultez la documentation MySQL sur la réinitialisation des autorisations.

Étapes suivantes

• Pour restaurer l'intégralité des données ou des bases de données et tables individuelles vers une autre instance RDS, consultez Restaurer l'intégralité des données ou Restaurer des bases de données et tables individuelles.

• Pour un aperçu complet des méthodes de restauration, consultez Aperçu des méthodes de restauration des données.