Restore full data of an ApsaraDB RDS for MySQL instance - ApsaraDB RDS

Restaurez une instance ApsaraDB RDS for MySQL vers une nouvelle instance RDS à l'aide des fichiers de sauvegarde des données et des journaux. Cette approche vous permet d'analyser les données historiques ou de récupérer des données après des opérations involontaires, sans affecter votre instance de production.

Prérequis

Avant de commencer, assurez-vous que :

L'instance RDS d'origine est dans l'état Running et n'est pas verrouillée.
Aucune tâche de migration n'est en cours sur l'instance RDS d'origine.
Au moins une sauvegarde des données a été effectuée (ApsaraDB RDS effectue des sauvegardes automatiques par défaut — consultez Overview of backup methods).
(Obligatoire pour la restauration à un instant précis) La sauvegarde des journaux est activée — consultez Use the log backup feature for an ApsaraDB RDS for MySQL instance.
(Obligatoire pour la restauration à partir d'un ensemble de sauvegarde) Au moins une sauvegarde physique a été effectuée — consultez Automatic backup.

Fonctionnement

La restauration complète des données crée une nouvelle instance RDS à partir de vos données de sauvegarde. L'instance d'origine reste inchangée tout au long du processus.

Élément	Description
Restoration range	L'intégralité de l'instance RDS est restaurée.
Specifications of the new RDS instance	Hérite des configurations de liste d'autorisation, de sauvegarde et de paramètres de l'instance d'origine.
Account information	Inclut les informations de compte au moment de la restauration, ainsi que les informations de compte issues du fichier de sauvegarde sélectionné.
Data	Correspond aux données contenues dans le fichier de sauvegarde spécifié de l'instance RDS d'origine.
Restore point	Dépend des fonctionnalités de sauvegarde activées : si la sauvegarde des journaux est désactivée, la restauration est possible uniquement à l'heure de création de la sauvegarde ; si elle est activée, la restauration est possible à n'importe quel moment durant la période de rétention des journaux ; si la récupération à un instant précis (PITR) est activée, la restauration est possible à n'importe quel instant en fonction du paramètre Time Range of Specific Points in Time for Restoration. Pour connaître les différences entre PITR et la sauvegarde des journaux, consultez Differences between the PITR and log backup features.

Limitations

Vous ne pouvez pas restaurer directement des fichiers de sauvegarde téléchargés vers une instance RDS for MySQL existante. Effectuez d'abord la restauration vers une nouvelle instance, vérifiez les données, puis migrez les données vers l'instance existante.
La restauration peut échouer si la nouvelle instance RDS exécute une version antérieure du moteur de base de données par rapport à l'instance d'origine.
La restauration peut échouer si les noms de tables ou de colonnes contiennent des caractères chinois ou spéciaux.
La restauration peut échouer si les journaux binaires de l'instance RDS d'origine ont été supprimés.
Les tables sans clés primaires ne peuvent pas être restaurées si le paramètre implicit_primary_key est défini sur off sur l'instance RDS d'origine.

Facturation

La nouvelle instance RDS est facturée dès sa création. Vérifiez le prix lors de la configuration de l'instance avant de confirmer la commande.

Pour une utilisation temporaire, créez une instance RDS avec facturation à l'utilisation ou serverless. Après avoir vérifié et migré les données vers l'instance d'origine, libérez la nouvelle instance pour arrêter la facturation. Consultez Migrate data between ApsaraDB RDS instances et Release or unsubscribe from an ApsaraDB RDS for MySQL instance.

Restaurer une instance complète

Il n'est pas nécessaire d'activer manuellement la fonctionnalité de restauration complète des données. Une fois l'instance RDS créée, le système effectue automatiquement des sauvegardes périodiques. Vous pouvez utiliser les fichiers de sauvegarde des données et des journaux générés pour restaurer l'intégralité des données à tout moment.

Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où se trouve l'instance RDS. Recherchez l'instance et cliquez sur son ID.
Dans le volet de navigation de gauche, cliquez sur Backup and Restoration.
Cliquez sur Restore Database.

Remarque
Vous pouvez également cliquer sur Restore Instance dans la section Instance Distribution de la page Basic Information.

Sur la page Restore Instance, sélectionnez un point de restauration ou un ensemble de sauvegarde, puis configurez les paramètres de l'instance.

Paramètre	Description
Billing Method	Subscription : payez à l'avance pour une utilisation à long terme à un coût unitaire inférieur. Pay-as-you-go : facturation horaire basée sur l'utilisation réelle ; libérez l'instance lorsqu'elle n'est plus nécessaire.
Restoration Mode	By Backup Set : restaurez à partir d'une sauvegarde physique spécifique. Les fichiers de sauvegarde logique ne sont pas pris en charge. By Point in Time : restaurez à n'importe quel instant durant la période de rétention des journaux. Disponible uniquement lorsque la sauvegarde des journaux est activée.
Product Type	Non affiché pour Basic Edition. Pour High-availability Edition : le stockage ESSD ou Premium ESSD prend en charge les types de produit Standard et YiTian ; le stockage Premium Local SSD prend en charge uniquement le type Standard. Pour Cluster Edition : les types de produit Standard et YiTian sont disponibles. Consultez Product types.
Zone of primary node et Zone of secondary node	Single-zone deployment : les nœuds primaire et secondaire se trouvent dans la même zone. Multi-zone deployment : les nœuds primaire et secondaire se trouvent dans des zones différentes pour la reprise après sinistre au niveau de la zone. Le déploiement multi-zone est recommandé. Après la création, consultez les détails de la zone sur la page Service Availability. Basic Edition prend en charge uniquement le déploiement mono-zone.
Instance Type	General-purpose instance types : mémoire et E/S dédiées ; CPU et stockage partagés avec d'autres instances sur le même hôte. Dedicated instance types : CPU, mémoire, stockage et E/S dédiés. La configuration de l'hôte dédié occupe exclusivement toutes les ressources de l'hôte. Pour connaître les cœurs, la mémoire, les connexions et les IOPS pris en charge par type d'instance, consultez Primary ApsaraDB RDS instance types. Remarque Chaque type d'instance prend en charge un nombre spécifique de cœurs, une capacité de mémoire, un nombre maximal de connexions et un nombre maximal d'IOPS. Pour plus d'informations, consultez Primary ApsaraDB RDS instance types.
Storage Capacity	Stockage maximal pour les fichiers de données, les fichiers système, les fichiers de journal binaire et les fichiers de transaction. Ajustable par incréments de 5 Go.

Cliquez sur Next: Instance Configuration et configurez les paramètres réseau.

Paramètre	Description
Network Type	Classic network : type de réseau traditionnel. VPC : recommandé. Un cloud privé virtuel (VPC) offre une sécurité et des performances supérieures. Lors de la sélection du VPC, configurez les paramètres VPC et vSwitch of Primary Node. Pour un déploiement multi-zone, configurez également vSwitch of Secondary Node. La nouvelle instance RDS et votre instance Elastic Compute Service (ECS) doivent utiliser le même type de réseau — et le même VPC si les deux utilisent un VPC — pour communiquer via un réseau interne.
Resource Group	Assignez l'instance à un groupe de ressources pour simplifier la gestion des ressources et des autorisations. Sélectionnez un groupe existant ou créez-en un. Si le regroupement n'est pas nécessaire, sélectionnez Default Resource Group.

Paramètre

Description

Network Type

Classic network : type de réseau traditionnel. VPC : recommandé. Un cloud privé virtuel (VPC) offre une sécurité et des performances supérieures. Lors de la sélection du VPC, configurez les paramètres VPC et vSwitch of Primary Node. Pour un déploiement multi-zone, configurez également vSwitch of Secondary Node. La nouvelle instance RDS et votre instance Elastic Compute Service (ECS) doivent utiliser le même type de réseau — et le même VPC si les deux utilisent un VPC — pour communiquer via un réseau interne.

Resource Group

Assignez l'instance à un groupe de ressources pour simplifier la gestion des ressources et des autorisations. Sélectionnez un groupe existant ou créez-en un. Si le regroupement n'est pas nécessaire, sélectionnez Default Resource Group.

Cliquez sur Next: Confirm Order.
Vérifiez la section Parameter Configuration, définissez la Quantity et la Subscription Duration (facturation par abonnement uniquement), cliquez sur Confirm Order, puis effectuez le paiement.

Remarque
Pour les instances par abonnement, activez l'option Auto-renew afin d'éviter les renouvellements manuels et les interruptions de service dues à des impayés.
(Facultatif) Connectez-vous à la nouvelle instance RDS et vérifiez les données.

Migrer les données restaurées vers l'instance d'origine

Après avoir vérifié les données sur la nouvelle instance RDS, utilisez Data Transmission Service (DTS) pour migrer certaines ou toutes les bases de données et tables vers l'instance d'origine.

Définissez la nouvelle instance RDS comme base de données source et l'instance RDS d'origine comme base de données de destination. Définissez Access Method sur Alibaba Cloud Instance pour les deux. Consultez Migrate data between ApsaraDB RDS for MySQL instances.

Selon votre objectif, choisissez la méthode appropriée après la restauration :

Remplacer les données de l'instance d'origine : migrez toutes les données de la nouvelle instance vers l'instance d'origine.
Récupérer des données spécifiques : écrivez et exécutez une tâche de migration qui extrait uniquement les bases de données ou tables concernées et les applique à l'instance d'origine.

Méthodes de restauration par destination

Destination	Méthodes disponibles
Instance RDS d'origine	Méthode 1 : restaurez vers une nouvelle instance, vérifiez, puis migrez les données sélectionnées vers l'instance d'origine. Méthode 2 : utilisez la fonctionnalité de restauration de bases de données et de tables pour restaurer directement. Méthode 3 : utilisez Database Backup (DBS) pour créer une sauvegarde logique, puis restaurez à l'aide du fichier de sauvegarde logique — consultez Restore a MySQL database from a logical backup.
Autre instance RDS existante	Méthode 1 : restaurez vers une nouvelle instance, vérifiez, puis migrez les données vers l'instance cible. Méthode 2 : utilisez DBS pour créer une sauvegarde logique et restaurer — consultez Restore a MySQL database from a logical backup.
Base de données gérée par l'utilisateur	Méthode 1 : restaurez vers une nouvelle instance, vérifiez, puis migrez les données. Méthode 2 : utilisez DBS pour créer une sauvegarde logique et restaurer — consultez Restore a MySQL database from a logical backup. Méthode 3 : Téléchargez un fichier de sauvegarde et restaurez à partir de celui-ci — consultez Restore from a physical backup, Restore from a logical backup, ou Restore using snapshot backup files.

Pour obtenir des instructions de restauration pour d'autres moteurs de base de données, consultez Restore SQL Server data, Restore the data of an ApsaraDB RDS for PostgreSQL instance, et Restore the data of an ApsaraDB RDS for MariaDB instance.

FAQ

Comment restaurer des bases de données individuelles qui ont été supprimées ?

Utilisez la fonctionnalité de restauration de bases de données et de tables pour restaurer des bases de données et des tables spécifiques. Si votre instance ne prend pas en charge cette fonctionnalité, restaurez les bases de données supprimées vers une nouvelle instance RDS, vérifiez les données, puis migrez-les vers l'instance d'origine.

Puis-je restaurer les données à un instant précis ?

Oui, si la sauvegarde des journaux est activée. Vous pouvez restaurer à n'importe quel instant durant la période de rétention des journaux. Si la sauvegarde des journaux est désactivée, vous ne pouvez restaurer qu'à l'heure de création de la sauvegarde des données. Pour vérifier la période de rétention des journaux, consultez Use the log backup feature.

Puis-je restaurer à un instant précis s'il n'existe aucun fichier de sauvegarde des données ?

Non. La récupération à un instant précis nécessite une sauvegarde complète des données effectuée avant l'instant cible, ainsi que les journaux binaires depuis cette sauvegarde jusqu'à l'instant cible. Sans sauvegarde complète, aucune des deux opérations ne peut être appliquée.

Si la période de rétention des sauvegardes est de sept jours, puis-je restaurer les données d'il y a sept jours ?

Non. Une fois la période de rétention expirée, les sauvegardes sont automatiquement supprimées et ne peuvent pas être récupérées.

Puis-je utiliser la fonctionnalité de suivi des données de Data Management (DMS) pour récupérer des sauvegardes supprimées ?

Non. Le suivi des données utilise les journaux binaires, qui sont également soumis à la période de rétention des sauvegardes. Les journaux binaires plus anciens que la période de rétention ne sont pas disponibles. Pour étendre la profondeur de récupération possible, augmentez la période de rétention des sauvegardes — consultez Automatic backup.

Pourquoi suis-je facturé pour la restauration des données ?

Les frais s'appliquent à la nouvelle instance RDS créée lors de la restauration, et non à l'opération de restauration elle-même. L'instance est facturée dès sa création. Consultez la section Facturation ci-dessus pour connaître les options permettant de minimiser les coûts.

Combien de temps faut-il pour restaurer les données vers une nouvelle instance RDS ?

La durée nécessaire pour restaurer les données vers une nouvelle instance RDS dépend du volume de données et des conditions réseau. Dans la plupart des cas, la restauration des données prend de quelques minutes à plusieurs heures.

Le temps requis varie en fonction du volume de données, des spécifications de l'instance, du type de stockage et de la complexité des journaux binaires. À titre de référence, la restauration de 200 Go de données sur une instance High-availability Edition avec 2 cœurs et 4 Go de mémoire, utilisant des disques Premium Local SSD, prend environ 3 heures (avec un temps d'application des journaux binaires de 30 minutes).

Exemple de durée requise pour la restauration des données

Le tableau suivant indique les durées nécessaires pour restaurer les données vers une nouvelle instance RDS disposant de 2 cœurs et de 4 Go de mémoire, exécutant RDS High-availability Edition avec des disques Premium Local SSD.

Opération	Durée requise
Créer une instance RDS	5 minutes
Configurer une instance RDS	15 minutes
Télécharger un fichier de sauvegarde	200 Go-heure
Démarrer une instance RDS	5 minutes
Télécharger un fichier de journal binaire	200 Go-heure
Appliquer un fichier de journal binaire	Selon le contenu

Remarque

Par exemple, si vous souhaitez restaurer 200 Go de données et que la durée nécessaire pour appliquer les fichiers de journaux binaires est de 30 minutes, la durée totale de la restauration est d'environ 3 heures. Cela s'applique si les données de sauvegarde et les journaux binaires sont téléchargés en série.
Si vous souhaitez restaurer les données plus rapidement, vous pouvez activer une instance sandbox. Le système synchronise automatiquement les données vers l'instance sandbox pour vous permettre d'effectuer une restauration rapide. Pour plus d'informations, consultez Use the emergency recovery feature.

Facteurs

La vitesse de restauration varie en fonction de plusieurs facteurs, et la restauration peut échouer dans certains cas. Vous devrez peut-être également résoudre manuellement les erreurs dues à l'exécution d'instructions SQL. Les facteurs suivants influencent la vitesse de restauration :

Volume de données : un volume de données de sauvegarde plus important ralentit la restauration.
Transactions volumineuses : les journaux binaires contenant des transactions volumineuses réduisent la vitesse.
Mises à jour de données fréquemment accédées : les journaux binaires avec des mises à jour à haute fréquence réduisent la vitesse.
Contraintes de clé étrangère : la surcharge de vérification réduit la vitesse.
Volume des journaux binaires : un plus grand nombre d'enregistrements de journaux binaires pour la récupération à un instant précis réduit la vitesse.
Storage type : les disques cloud permettent une restauration plus rapide que les disques Premium Local SSD.
Spécifications de l'instance : des spécifications supérieures améliorent la vitesse.
Version du moteur de base de données : les versions prenant en charge la réplication parallèle permettent une restauration plus rapide.

Important

Les facteurs suivants peuvent provoquer des échecs de restauration :

Pourquoi ne puis-je pas sélectionner un vSwitch dans la liste déroulante vSwitch of Primary Node ?

Aucun vSwitch n'existe dans la zone sélectionnée à l'étape précédente. Cliquez sur le link dans la liste déroulante pour accéder à la console VPC, créez un vSwitch dans la zone requise, puis revenez pour le sélectionner.

Étapes suivantes

Pour restaurer des bases de données ou des tables individuelles au lieu de l'instance entière, consultez Restore individual databases and tables of an ApsaraDB RDS for MySQL instance.
Pour un aperçu de toutes les options de restauration, consultez Overview of data restoration methods.