À propos de la restauration d'une instance

MySQL | PostgreSQL | SQL Server

Cette page fournit des informations que vous devez consulter avant de restaurer une instance à partir d'une sauvegarde ou d'effectuer une récupération à un moment précis.

Remarque : Cette page contient des fonctionnalités liées aux éditions Cloud SQL. Pour en savoir plus sur les éditions Cloud SQL, consultez la page Présentation des éditions Cloud SQL.

Que se passe-t-il lors d'une restauration ?

Pour les éditions Cloud SQL Enterprise et Cloud SQL Enterprise Plus, vous pouvez restaurer une instance à partir d'une sauvegarde. Vous pouvez également restaurer des sauvegardes sur des instances de différentes éditions.

Lorsque vous restaurez une instance, les données suivantes de l'instance principale sont restaurées sur la nouvelle instance :

• Bases de données
• Utilisateurs

Remarque : Les options de l'instance principale ne sont pas restaurées. Toutes les options précédemment définies sur l'instance cible sont conservées après la restauration.

L'opération de restauration entraîne le redémarrage de l'instance.

Récupération à un moment précis (PITR)

La récupération à un moment précis (PITR) vous aide à récupérer l'état précédent d'une instance à un moment spécifique. Par exemple, en cas de perte de données due à une erreur, vous pouvez restaurer une base de données à l'état qui précède l'occurrence de l'erreur.

La récupération PITR crée toujours une nouvelle instance. Vous ne pouvez pas effectuer de récupération PITR sur une instance existante. La nouvelle instance hérite des paramètres de l'instance source, de la même manière que lors d'une création de clone. Toutefois, pour que la nouvelle instance hérite de ces paramètres, son état doit être RUNNABLE.

Lorsque vous créez une instance Cloud SQL dans la console Google Cloud, la récupération PITR est activée par défaut.

La récupération PITR utilise la journalisation binaire pour archiver les journaux. Par défaut, la récupération PITR est activée pour les instances Cloud SQL Enterprise Plus.

Lorsque vous restaurez une sauvegarde sur une instance Cloud SQL avant d'activer la récupération PITR, vous perdez les journaux archivés permettant d'utiliser la récupération PITR. Si la taille de vos journaux binaires sur le disque entraîne des problèmes de performances pour votre instance, désactivez la récupération PITR, puis réactivez-la. Cela garantit que les nouveaux journaux sont stockés dans Cloud Storage plutôt que sur le disque.

Attention : Si vous désactivez et réactivez la récupération PITR, tous les journaux existants sont supprimés et vous ne pouvez pas effectuer de récupération PITR antérieure à l'heure où vous l'avez réactivée. L'activation de la récupération PITR nécessite de redémarrer la base de données.

Pour obtenir des instructions détaillées sur l'exécution d'une récupération PITR, consultez la page Utiliser la récupération à un moment précis (PITR).

Conseils généraux pour effectuer une restauration

Lorsque vous restaurez une instance à partir d'une sauvegarde (de la même instance ou d'une autre instance), gardez à l'esprit les éléments suivants :

• L'opération de restauration écrase toutes les données de l'instance cible.
• L'instance cible n'est pas disponible pour les connexions pendant l'opération de restauration ; les connexions existantes sont perdues.
• Si vous cherchez à restaurer une instance qui possède des instances dupliquées avec accès en lecture, vous devez supprimer toutes les instances dupliquées et les recréer une fois l'opération de restauration terminée.
• L'opération de restauration redémarre l'instance.

Pour obtenir des instructions détaillées sur l'exécution d'une restauration, consultez la page :

• Restaurer une instance

Conseils et prérequis pour restaurer une autre instance

Lorsque vous restaurez une sauvegarde d'une autre instance, tenez compte des restrictions et des bonnes pratiques ci-dessous :

• L'instance cible doit avoir la même version de base de données que l'instance à partir de laquelle la sauvegarde a été effectuée.

  Si vous souhaitez mettre à niveau la version de base de données pour votre instance, suivez les étapes de la section Mettre à niveau la version majeure de la base de données sur place.

• Cloud SQL définit toujours la capacité de stockage de l'instance cible sur la valeur maximale de la taille du disque configuré et du disque de sauvegarde. La taille du disque de sauvegarde est égale à celle du disque au moment de la sauvegarde.

• La capacité de stockage de l'instance cible doit être au moins égale à la capacité de l'instance en cours de sauvegarde. La quantité de stockage utilisée n'a pas d'importance. Vous pouvez consulter la capacité de stockage de l'instance sur la page Instances Cloud SQL de la console.

• L'instance cible doit être à l'état RUNNABLE.

• L'instance cible peut ne pas posséder le même nombre de cœurs ni la même quantité de mémoire que l'instance à partir de laquelle la sauvegarde a été effectuée.

• L'instance cible peut se trouver dans une région différente de celle de l'instance source.

• Lors d'une panne, vous pouvez toujours récupérer la liste des sauvegardes d'un projet particulier. Consultez la section Afficher les sauvegardes en cas de panne.

Limitations de la fréquence de restauration

Vous êtes autorisé à effectuer au maximum trois opérations de restauration toutes les 30 minutes par instance, par région et par projet. Si une opération de restauration échoue, elle n'est pas comptabilisée dans ce quota. Si vous atteignez la limite, l'opération échoue avec un message d'erreur vous indiquant quand vous pouvez relancer l'opération.

Examinons comment Cloud SQL limite la fréquence des restaurations.

Cloud SQL utilise les jetons d'un bucket pour déterminer combien d'opérations de restauration sont disponibles à un moment donné. Pour chaque sauvegarde, il existe un bucket pour chaque projet et région cible. Les instances cibles d'un même projet partagent un bucket si elles se trouvent dans la même région. Vous pouvez utiliser jusqu'à trois jetons par bucket pour les opérations de restauration. Toutes les 10 minutes, un nouveau jeton est ajouté au bucket. Si le bucket est plein, le jeton "déborde".

Chaque fois que vous effectuez une opération de restauration, un jeton est attribué à partir du bucket. Si l'opération réussit, le jeton est supprimé du bucket. En cas d'échec, le jeton est renvoyé au bucket. Le schéma suivant illustre ce fonctionnement :

Par exemple, dans la figure suivante, "Backup1", "Backup2" et "Backup3" sont les sauvegardes de la même instance source.

• Chaque sauvegarde (Backup1, Backup2 et Backup3) dispose de son propre bucket de jetons pour les opérations de restauration qui ciblent différentes instances du Projet 1 dans la Région A (Bucket11A, Bucket21A et Bucket31A). Comme chaque sauvegarde possède son propre bucket, vous pouvez restaurer chaque sauvegarde sur la même instance trois fois toutes les trente minutes.
• Chaque sauvegarde comporte un bucket pour un projet distinct et pour une région distincte. Par exemple, s'il existe cinq projets dans une région, il existe cinq buckets pour cette sauvegarde dans cette région, un dans chaque projet. Dans la figure précédente, nous avons deux projets dans la région A : le Projet 1 et le Projet n.
  • Backup1 comporte deux buckets de jetons pour les opérations de restauration dans la Région A. Un bucket pour le Projet 1 (Bucket11A) et un bucket pour le Projet n (Bucket1nA).
  • De même, Backup3 comporte deux buckets pour les opérations de restauration dans la Région A. Un pour le Projet 1 (Bucket31A) et un pour le Projet n (Bucket3nA).
• Backup3 comporte un bucket dans la Région B, pour le Projet 1, car toutes les instances du même projet cible et de la même région cible partagent un bucket.

Étapes suivantes

• Effectuer une restauration à partir d'une sauvegarde
• Utiliser la récupération à un moment précis (PITR)