Vous pouvez restaurer une sauvegarde d'une base de données Spanner dans une nouvelle base de données. La
la base de données restaurée contiendra toutes les données et le schéma de la base de données d'origine
au niveau de l'version_time
de la sauvegarde, y compris toutes les options de base de données définies
avec l'ALTER DATABASE SET OPTIONS
. Il ne disposera d'aucune autorisation IAM (à l'exception de
(héritée de l'instance contenant la base de données restaurée) et vous devez
d'appliquer les autorisations IAM appropriées
une fois la restauration terminée.
Il n'inclut pas les données internes de tous les flux de modifications. Lorsque vous restaurez
à partir d'une sauvegarde, celle-ci se trouve dans le même emplacement,
comme sauvegarde source. Si vous devez effectuer une restauration à partir de la sauvegarde
une région ou un projet différent pour des raisons de conformité ou de continuité des activités, vous
pouvez copier la sauvegarde sur
une instance d'une région ou d'un projet distinct, puis restaurer à partir de la copie
sauvegarde.
Vous pouvez restaurer à partir d'une sauvegarde de l'une des manières suivantes :
- Dans la console Google Cloud
- À l'aide de la Google Cloud CLI
- À l'aide des bibliothèques clientes
- À l'aide de l'API REST ou RPC API
Fonctionnement de la restauration de la base de données à partir d'une sauvegarde
Lorsque vous restaurez une base de données Spanner, vous devez spécifier une sauvegarde source et une nouvelle base de données cible. Vous ne pouvez pas restaurer une sauvegarde vers une base de données existante.
La base de données nouvellement restaurée doit se trouver dans le même projet que la sauvegarde, sur une instance ayant la même configuration d'instance et la même édition Spanner (ou de niveau supérieur) que la sauvegarde. Par exemple, si une sauvegarde se trouve sur une instance configurée dans la région us-west3
et utilise l'édition Enterprise, elle peut être restaurée sur toute instance du projet qui est également configurée dans la région us-west3
et utilise l'édition Enterprise. Si vous restaurez une sauvegarde dans un
Instance de l'édition Enterprise vers l'édition Standard
la restauration peut échouer si la base de données utilise
les fonctionnalités de l'édition Enterprise. La capacité de calcul du
n'a pas besoin d'être identique.
Le processus de restauration est conçu pour la haute disponibilité. La base de données peut être restaurée à condition que le quorum majoritaire des régions et des zones de l'instance soit disponible.
Pour restaurer une sauvegarde avec CMEK activé, la clé et la version de clé doivent être disponibles pour Spanner. La base de données restaurée utilise par défaut les mêmes configurations de chiffrement que la sauvegarde. Vous pouvez ignorer ce comportement en spécifiant une autre configuration de chiffrement lors de la restauration de la base de données. Pour en savoir plus, consultez la section Restaurer à partir d'une sauvegarde avec CMEK activé.
Restaurer une sauvegarde dans une autre région ou un autre projet
Si vous devez restaurer la sauvegarde dans une autre région ou un autre projet, commencez par copiez la sauvegarde la région ou le projet choisi. Les sauvegardes copiées peuvent être restaurées dès que la copie se termine. Vous pouvez restaurer la sauvegarde dans l'instance de destination (à condition qu'elle utilise la même édition que l'instance de sauvegarde source) ou dans n'importe quelle instance ayant la même configuration d'instance et la même édition (ou une édition supérieure) que l'instance de destination. Avant la restauration, assurez-vous que l'instance de destination dispose de suffisamment de nœuds ou d'unités de traitement provisionnées pour gérer la taille de la base de données ; selon la limite de stockage de 10 To par nœud (vous devez disposer d'au moins pour restaurer une sauvegarde de 20 To). Si vous avez copié la sauvegarde dans un autre projet et que vous souhaitez la restaurer, assurez-vous que votre projet de destination dispose d'un nombre suffisant de quotas de nœuds pour la restauration. Restauration d'une copie sauvegarde fonctionne de la même manière qu'une restauration normale.
États de restauration
Une base de données restaurée passe par trois états, suivis par deux opérations de longue durée.
CREATING
: Spanner commence la restauration en créant une base de données et en montant des fichiers à partir de la sauvegarde. Au cours de cet étatCREATING
initial, la base de données restaurée n'est pas encore prête à être utilisée. Cet état prend généralement une heure. Une fois l'étatCREATING
terminé, votre base de données est prête à l'emploi.Pour suivre la progression de cet état, vous pouvez interroger la requête de restauration de longue durée opération qui Spanner est mis à disposition au cours de ce processus. Elle renvoie un objet
RestoreDatabaseMetadata
.Notez les mises en garde suivantes concernant l'état
CREATING
:- Si vous restaurez une instance différente, l'opération de restauration appartient à l'instance contenant la base de données restaurée, et non à l'instance contenant la sauvegarde.
- Spanner ne vous autorise pas à supprimer la sauvegarde tant qu'elle est
en cours de restauration. Vous pouvez le supprimer une fois la restauration terminée et que la base de données passe à l'état
READY
. - Une instance ne peut pas avoir plus de dix bases de données associées à l'état
CREATING
en raison de la restauration à partir de sauvegardes. Vous ne pourrez pas restaurer une autre sauvegarde à l'instance jusqu'à ce que l'une des dix bases de données restaurées passe à l'étatREADY_OPTIMIZING
ouREADY
;
READY_OPTIMIZING
: une fois la sauvegarde montée par Spanner, il commence à copier les données de sauvegarde dans la nouvelle base de données tout en optimisant sa taille de stockage. Votre base de données est prête à l'emploi pendant ce processus. Cette phase de la restauration prend généralement quelques heures pour les bases de données de moins de 100 To.Bien que vous puissiez utiliser votre base de données comme d'habitude pendant
READY_OPTIMIZING
, les mises en garde suivantes s'appliquent :- Les latences de lecture peuvent être légèrement supérieures à la normale.
- Les métriques de stockage affichent la taille de la nouvelle base de données, et non de la sauvegarde. Par conséquent, tant que le transfert de données est en cours, les métriques de stockage Spanner peuvent afficher des résultats qui ne reflètent pas la taille totale de toutes vos données.
- Comme pour l'état
CREATING
, Spanner ne vous permet pas de supprimer la sauvegarde installée.
Spanner met à disposition une autre opération de restauration de longue durée pendant cet état, cette fois en renvoyant un objet de métadonnées
OptimizeRestoredDatabaseMetadata
.READY
: une fois l'opération de copie et d'optimisation terminée, la base de données passe à l'étatREADY
. La base de données est entièrement restaurée et ne fait plus référence à la sauvegarde ni n'en a plus besoin.
Contrôle des accès (IAM)
Le rôle spanner.restoreAdmin
vous autorise à effectuer une restauration à partir d'une sauvegarde.
Pour en savoir plus, consultez la page Contrôle des accès avec IAM.
Les rôles suivants ont également accès aux opérations de restauration Spanner:
spanner.admin
: dispose d'un accès complet à la restauration. Ce rôle comprend un accès complet à toutes les ressources Spanner.owner
: dispose d'un accès complet à la restauration.editor
: dispose d'un accès complet pour la restauration.viewer
: peut afficher les restaurations et les opérations de restauration. Ce rôle ne peut pas créer, mettre à jour, supprimer ni copier une sauvegarde.
Tarifs
Aucuns frais ne s'appliquent pour la restauration d'une sauvegarde.
Étape suivante
- Pour restaurer une base de données à partir d'une sauvegarde, consultez Restaurez à partir d'une sauvegarde.