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.
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
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.
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 WAL (Write-Ahead Logging). 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 WAL 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.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).
Restaurer une instance indisponible
Vous pouvez utiliser la récupération PITR pour restaurer une instance Cloud SQL indisponible. La récupération PITR propose généralement un objectif de point de récupération de cinq minutes ou moins.
Si l'instance est indisponible, vous pouvez utiliser l'API pour vérifier la dernière heure à laquelle vous pouvez restaurer l'instance et effectuer une récupération à ce moment précis. Si la zone dans laquelle l'instance est configurée n'est pas accessible, vous pouvez cloner l'instance sur une autre zone.
Supposons qu'une instance Cloud SQL devienne indisponible à 16h00 EST. Si le dernier horaire de récupération est 15h55 EST, vous pouvez restaurer l'instance à ce moment précis.
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 :
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.
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)