Présentation de la restauration d'une instance

Cloud SQL vous permet de restaurer vos instances à partir d'une sauvegarde ou en effectuant une récupération à un moment précis (PITR). Cela vous permet de récupérer une instance à une période ou un moment précis en restaurant la sauvegarde sur une instance existante ou sur une nouvelle instance. Pour effectuer une restauration, vous pouvez utiliser la sauvegarde d'une instance active ou supprimée. L'opération de restauration prend les paramètres, les bases de données et les utilisateurs de l'instance source, et les définit dans l'instance cible de votre choix.

Lorsque vous effectuez une restauration sur une nouvelle instance, l'instance cible peut se trouver dans une région ou un projet différents de ceux de l'instance source. L'instance cible peut également utiliser un nombre de cœurs ou une quantité de mémoire différents de ceux de l'instance source.

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.

Lorsque vous restaurez une instance, tenez compte des points suivants :

  • L'opération de restauration écrase toutes les données de l'instance cible.
  • Les options de l'instance source 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'instance cible n'est pas disponible pour les connexions pendant l'opération de restauration ; les connexions existantes sont perdues.
  • Si vous restaurez une instance qui possède des instances répliquées avec accès en lecture, vous devez supprimer toutes les instances répliquées et les recréer une fois l'opération de restauration terminée.
  • L'opération de restauration redémarre l'instance.
  • Après la restauration à partir d'une sauvegarde, les configurations de sauvegarde de l'instance cible sont définies sur les valeurs par défaut. Si votre instance source disposait de configurations de sauvegarde personnalisées ou utilisait des sauvegardes améliorées, vous devrez mettre à jour les configurations de sauvegarde une fois la restauration terminée.

Restaurer à l'aide d'une sauvegarde

Cloud SQL vous permet de restaurer une instance à l'aide d'une sauvegarde. Vous pouvez utiliser une sauvegarde d'une instance active ou supprimée pour la restaurer sur une instance nouvelle ou existante. Vous pouvez utiliser n'importe quelle sauvegarde disponible pour restaurer l'instance. Pour en savoir plus sur le fonctionnement des sauvegardes dans Cloud SQL, consultez Présentation des sauvegardes.

Lorsque vous restaurez une instance à l'aide d'une sauvegarde, vous pouvez effectuer les opérations suivantes :

  • Restaurer dans une nouvelle instance
  • Restaurer sur une instance existante
  • Effectuer une restauration sur une instance d'un autre projet ou d'une autre région

En cas de panne, vous pouvez toujours récupérer la liste des sauvegardes d'un projet particulier à partir duquel effectuer la restauration.

Pour restaurer votre instance à l'aide d'une sauvegarde, consultez Restaurer une instance à l'aide d'une sauvegarde.

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

La récupération à un moment précis vous permet de restaurer votre instance à un moment spécifique de la base de données. 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. Contrairement à la restauration à l'aide d'une sauvegarde, 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.

Si vous créez une instance Cloud SQL Enterprise Plus, la récupération PITR est activée par défaut. Vous devez désactiver manuellement la fonctionnalité.

Si vous créez une instance Cloud SQL Enterprise dans la console Google Cloud , la récupération PITR est activée par défaut. Sinon, si vous créez l'instance à l'aide de gcloud CLI, de Terraform ou de l'API Cloud SQL Admin, la récupération à un moment précis est désactivée par défaut. Pour activer la récupération PITR pour ces instances, vous devez l'activer manuellement.

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

Stockage des journaux pour la récupération PITR

La récupération PITR utilise la journalisation WAL (Write-Ahead Logging) pour archiver les journaux. Lorsque vous restaurez une instance existante à l'aide d'une sauvegarde, ces journaux d'archive sont supprimés et ne sont pas disponibles pour effectuer une récupération à un moment précis. Seuls les nouveaux journaux générés après la restauration peuvent être utilisés pour la restauration à un instant donné.

Le 9 janvier 2023, nous avons lancé le stockage des journaux de transactions pour la récupération PITR dans Cloud Storage. Depuis ce lancement, les conditions suivantes s'appliquent :

  • Toutes les instances de l'édition Cloud SQL Enterprise Plus stockent leurs journaux WAL utilisés pour la récupération à un moment précis dans Cloud Storage. Seules les instances Cloud SQL Enterprise Plus que vous avez mises à niveau depuis l'édition Cloud SQL Enterprise avant le 1er avril 2024 et pour lesquelles la récupération PITR a été activée avant le 9 janvier 2023 continuent de stocker leurs journaux pour la récupération PITR sur le disque.

  • Les instances Cloud SQL Enterprise créées avec la récupération PITR activée avant le 9 janvier 2023 continuent de stocker leurs journaux pour la récupération PITR sur le disque.

  • Si vous mettez à niveau une instance Cloud SQL Enterprise après le 9 janvier 2023 qui stocke les journaux de transactions pour la récupération PITR sur disque vers l'édition Cloud SQL Enterprise Plus, le processus de mise à niveau change l'emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis vers Cloud Storage. Pour en savoir plus, consultez Mettre à niveau une instance vers Cloud SQL Enterprise Plus en utilisant la mise à niveau sur place.

  • Toutes les instances Cloud SQL Enterprise que vous créez avec la récupération PITR activée après le 9 janvier 2023 stockent les journaux utilisés pour la récupération PITR dans Cloud Storage.

Si votre instance utilise Cloud Storage pour stocker les journaux préalables, ceux-ci sont stockés dans la même région que l'instance principale. Ces journaux sont stockés pendant 35 jours maximum pour l'édition Cloud SQL Enterprise Plus et pendant sept jours pour l'édition Cloud SQL Enterprise. Ils ne génèrent aucun coût supplémentaire par instance.

Pour savoir comment vérifier l'emplacement de stockage des journaux de transactions utilisés pour la récupération PITR, consultez Vérifier l'emplacement de stockage des journaux de transactions pour votre instance.

Pour les instances qui ne stockent les journaux WAL que sur le disque, vous pouvez changer l'emplacement de stockage des journaux de transactions utilisés pour la récupération PITR du disque vers Cloud Storage à l'aide de gcloud CLI ou de l'API Cloud SQL Admin. Pour en savoir plus, consultez la section Passer au stockage des journaux de transactions dans Cloud Storage.

Pour vous assurer que les journaux de votre instance sont stockés dans Cloud Storage plutôt que sur le disque, procédez comme suit :

  • Vérifiez l'architecture réseau de l'instance. Si l'instance utilise l'ancienne architecture réseau, mettez-la à niveau vers la nouvelle architecture réseau.

  • Si la taille de vos journaux sur le disque entraîne des problèmes de performances pour votre instance, désactivez la récupération à un moment précis, puis réactivez-la. Cela garantit que les nouveaux journaux sont stockés dans Cloud Storage plutôt que sur le disque.

Durée de conservation des journaux

Cloud SQL conserve les journaux de transactions dans Cloud Storage jusqu'à atteindre la valeur définie dans le paramètre de configuration de la récupération PITR transactionLogRetentionDays. Cette valeur peut aller de 1 à 35 jours pour l'édition Cloud SQL Enterprise Plus et de 1 à 7 jours pour l'édition Cloud SQL Enterprise. Si aucune valeur n'est définie pour ce paramètre, la durée de conservation des journaux de transactions par défaut est de 14 jours pour les instances Cloud SQL Enterprise Plus et de sept jours pour les instances de l'édition Cloud SQL Enterprise. Pour en savoir plus sur la définition des jours de conservation des journaux de transactions, consultez Définir la durée de conservation des journaux de transactions.

Bien qu'une instance stocke les journaux WAL utilisés pour la récupération à un moment précis dans Cloud Storage, elle conserve également un nombre plus faible de journaux WAL sur le disque pour permettre leur réplication sur Cloud Storage. Par défaut, lorsque vous créez une instance pour laquelle la récupération PITR est activée, l'instance stocke ses journaux WAL pour la récupération PITR dans Cloud Storage. Cloud SQL définit également la valeur des options expire_logs_days et binlog_expire_logs_seconds sur l'équivalent d'un jour automatiquement. Cela se traduit par un jour de journaux sur le disque.

Pour les journaux WAL (Write-Ahead Logging) utilisés pour la récupération PITR qui sont stockés sur le disque, qui sont en cours de transfert vers Cloud Storage ou qui y sont déjà stockés, Cloud SQL les conserve selon la valeur minimale définie pour l'une des configurations suivantes :

  • Le paramètre de configuration de sauvegarde transactionLogRetentionDays
  • L'option expire_logs_days ou binlog_expire_logs_seconds

Cloud SQL ne définit aucune valeur pour ces indicateurs si les journaux write-ahead sont stockés sur le disque, sont en cours de transfert vers Cloud Storage ou ont déjà été transférés vers Cloud Storage. Lorsque les journaux sont stockés sur le disque, la modification des valeurs de ces options peut affecter le comportement de la récupération PITR et le nombre de jours durant lesquels les journaux sont stockés sur le disque. Vous ne pouvez pas modifier les valeurs des indicateurs pendant que l'emplacement de stockage des journaux est transféré vers Cloud Storage. Nous vous déconseillons également de configurer la valeur de l'une ou l'autre de ces options sur 0. Pour en savoir plus, consultez Configurer des options de base de données.

  • Paramètre de configuration transactionLogRetentionDays
  • Option de base de données expire_logs_days
  • Option de base de données binlog_expire_logs_seconds

Par exemple, pour éviter les problèmes de performances, réduisez la valeur des indicateurs d'un jour par jour sur plusieurs jours. Par conséquent, Cloud SQL ne supprime pas tous les journaux WAL en même temps.

Pour les instances où la clé de chiffrement gérée par le client (CMEK) est activée, les journaux préalables sont chiffrés à l'aide de la dernière version de CMEK. Pour effectuer une restauration, la dernière version de la clé est requise pour tous les jours conservés dans le paramètre retained-transaction-log-days.

Limites de la PITR

Les limites suivantes sont associées à l'activation de la récupération PITR sur votre instance et à la taille de vos journaux de transactions sur le disque qui pose problème pour votre instance :

  • Vous pouvez désactiver la récupération à un moment précis et la réactiver pour vous assurer que Cloud SQL stocke les journaux dans Cloud Storage dans la même région que l'instance. Toutefois, Cloud SQL supprime tous les journaux existants. Vous ne pouvez donc pas effectuer d'opération de récupération à un moment précis antérieure à la date à laquelle vous avez réactivé la récupération à un moment précis.
  • Vous pouvez augmenter l'espace de stockage disponible sur l'instance. Sachez toutefois qu'une augmentation importante de l'espace disque occupé par vos journaux de transaction peut être temporaire.
  • Pour éviter les problèmes de stockage inattendus, nous vous recommandons d'activer l'augmentation automatique de l'espace de stockage. Cette recommandation ne s'applique que si la récupération PITR est activée sur votre instance et que vos journaux sont stockés sur le disque.

Pour obtenir des instructions détaillées sur l'exécution d'une récupération PITR, consultez [Utiliser la récupération à un moment précis (PITR)][perform-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 obtenir la première et la dernière heure de récupération à 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 restaurer l'instance dans une autre zone principale ou secondaire en indiquant des valeurs pour les zones de votre choix.

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.

Restaurer une instance supprimée à l'aide de la récupération à un moment précis (PITR)

Vous pouvez utiliser la récupération PITR pour restaurer une instance Cloud SQL après sa suppression. Pour utiliser cette fonctionnalité, votre instance doit avoir les options PITR et sauvegardes conservées activées avant d'être supprimée. Lorsque la récupération à un moment précis est activée, les journaux sont conservés après la suppression de l'instance.

Une fois une instance supprimée, les journaux de récupération à un moment précis continuent de suivre les paramètres de conservation définis par l'instance lorsqu'elle était active. Les journaux PITR expirent en fonction des paramètres de conservation de manière continue après la suppression de l'instance. La période mobile est définie en fonction de la période de conservation PITR définie sur l'instance avant sa suppression. Par exemple, si la durée de conservation de la récupération à un moment précis de votre instance Cloud SQL Enterprise Plus est définie sur 14 jours, le dernier journal de récupération à un moment précis sera supprimé 14 jours après la suppression de l'instance. Une fois qu'un journal PITR a expiré, il ne peut pas être récupéré.

Étant donné que les noms d'instance peuvent être réutilisés après la suppression d'une instance dans Cloud SQL, les journaux de récupération PITR conservés peuvent être identifiés dans Google Cloud avec les champs suivants :

  • instance_deletion_time
  • log_retention_days

Ces champs vous permettent d'identifier si un journal PITR appartient à une instance supprimée.

La période de récupération PITR est définie comme les heures de récupération les plus anciennes et les plus récentes disponibles pour restaurer votre instance à l'aide de la récupération PITR. Pour connaître les heures de récupération les plus anciennes et les plus récentes de votre instance supprimée, consultez Obtenir les heures de récupération les plus anciennes et les plus récentes.

Pour restaurer une instance à l'aide de la récupération PITR après sa suppression, consultez Effectuer une récupération PITR sur une instance supprimée.

Conditions requises pour la restauration sur une nouvelle instance

Lorsque vous restaurez votre instance sur une nouvelle instance, tenez compte des exigences suivantes :

  • 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.

  • 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.

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.

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 :

Fonctionnement des jetons

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

Jetons pour limiter la fréquence des opérations de restauration

  • 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