Déplacer une instance

Cette page explique comment déplacer une instance dans Spanner.

Vous pouvez déplacer votre instance Spanner d'une configuration d'instance vers une autre configuration d'instance, y compris entre des configurations régionales, birégionales et multirégionales. Le déplacement de votre instance n'entraîne pas de temps d'arrêt, et Spanner continue de fournir les garanties de transaction habituelles, y compris une cohérence forte, pendant le déplacement.

Vous pouvez également déplacer votre instance de sa configuration d'instance source vers une configuration d'instance personnalisée (par exemple, une configuration de base nam3 avec une instance répliquée en lecture seule us-west2). Comme vous ne pouvez pas mettre à jour la topologie des configurations d'instances existantes, vous devez d'abord créer une nouvelle configuration d'instance personnalisée avec la topologie de votre choix. Après avoir créé la configuration d'instance personnalisée, vous pouvez déplacer votre instance de la configuration d'instance source vers la nouvelle configuration d'instance personnalisée.

Pourquoi déplacer votre instance Spanner ?

Voici quelques-uns des avantages du déplacement de votre instance :

  • Augmenter la disponibilité : obtenez une disponibilité de 99,999% sans temps d'arrêt après avoir effectué un déplacement régional vers un emplacement birégional ou multirégional.
  • Réduire la latence : réduisez la latence et augmentez la couverture géographique avec des instances répliquées en lecture seule supplémentaires en passant d'une région à un emplacement birégional ou multirégional, ou d'un emplacement multirégional à un autre.
  • Réduire les coûts : réduisez les coûts horaires en passant d'une configuration birégionale ou multirégionale à une configuration régionale.
  • Colocaliser la base de données : colocalisez la base de données Spanner avec l'application cliente en déplaçant l'instance vers un emplacement plus optimisé.

Tarifs

Lors du déplacement d'une instance, les configurations des instances source et de destination sont soumises à des frais de calcul et de stockage horaires. Une fois le déplacement terminé, le stockage de l'instance vous est facturé selon la configuration de destination.

Si vous déplacez votre instance vers une nouvelle configuration d'instance régionale, birégionale ou multirégionale, des frais de transfert de données sortantes peuvent s'appliquer. Pour en savoir plus, consultez la page Tarifs de Spanner.

Limites

  • Pour déplacer votre instance, elle doit disposer d'au moins un nœud (1 000 unités de traitement).
  • Vous ne pouvez pas déplacer votre instance entre des projets ou des comptes Google Cloud .
  • Vous ne pouvez pas déplacer une instance qui utilise l'édition Standard directement d'une configuration d'instance régionale vers une configuration d'instance birégionale ou multirégionale. Vous devez d'abord mettre à niveau l'édition de votre instance vers l'édition Enterprise Plus, puis déplacer l'instance.
  • Si vous avez des requêtes actives utilisant un point de terminaison de service régional sur l'une des ressources de l'instance, le déplacement de l'instance a un impact sur toutes les requêtes qui utilisent le point de terminaison régional, car l'application régionale bloque l'accès aux instances interrégionales. Les requêtes qui utilisent un point de terminaison global ne sont pas affectées.
  • Les sauvegardes et les programmations de sauvegarde Spanner sont spécifiques à une configuration d'instance et ne sont pas incluses lors du déplacement d'une instance. Vous devez supprimer toutes les sauvegardes et programmations de sauvegarde existantes sur l'instance avant de commencer le déplacement. Pour en savoir plus, consultez Sauvegardes et programmations de sauvegarde.
  • Les API suivantes sont désactivées lors du déplacement d'une instance :
    • InstanceAdmin.DeleteInstance
    • InstanceAdmin.UpdateInstance
    • InstanceAdmin.CreateInstancePartition
    • InstanceAdmin.UpdateInstancePartition
    • InstanceAdmin.DeleteInstancePartition
    • DatabaseAdmin.CreateDatabase
    • DatabaseAdmin.UpdateDatabaseDdl (désactivé si default_leader est spécifié dans la requête).
    • DatabaseAdmin.RestoreDatabase
    • DatabaseAdmin.CreateBackup
    • DatabaseAdmin.CreateBackupSchedule
    • DatabaseAdmin.CopyBackup
  • Si une base de données possède un leader par défaut modifié, la sélection est conservée si elle nomme une région en lecture-écriture dans la configuration de l'instance de destination, et que cette configuration est multirégionale. Si la configuration de destination est régionale ou n'inclut pas la région en lecture/écriture nommée, la sélection de l'instance dupliquée principale par défaut est effacée.
  • Le déplacement d'une instance modifie l'attribut de configuration de votre instance. Si vous gérez vos ressources Spanner par le biais de l'automatisation, veillez à préparer et à résoudre les incohérences qui pourraient survenir.
    • Par exemple, si vous utilisez Terraform pour gérer vos instances et bases de données Spanner, et que vous activez terraform apply --auto-approve pour synchroniser vos ressources, toutes les instances et ressources enfants sont supprimées lorsque nous déplaçons l'instance. Mettez à jour la configuration en conséquence pour éviter la suppression et la perte de données. Pour en savoir plus sur la commande apply, consultez Options d'application Terraform.
  • Pendant le déplacement de l'instance, les métriques et les graphiques de surveillance Spanner peuvent afficher des données dans les configurations d'instance source et de destination, ou ne refléter que les performances d'une seule configuration d'instance.
  • Si vous avez configuré l'outil Autoscaler Open Source, vous n'avez pas besoin de le désactiver. Elle échoue, car InstanceAdmin.UpdateInstance (utilisé pour les modifications de nœuds et d'unités de traitement) est désactivé.
  • Vous ne pouvez pas déplacer une instance si la fonctionnalité d'autoscaler géré Spanner est activée sur celle-ci. Avant de déplacer l'instance, passez de l'autoscaling géré à l'allocation manuelle avec suffisamment de nœuds ou d'unités de traitement pour prendre en charge votre pic d'utilisation du processeur (par exemple, en exécutant gcloud spanner instances update INSTANCE_ID --nodes=PEAK_NODES). Une fois le déplacement terminé, vous pouvez réactiver l'autoscaler géré.
  • Vous ne pouvez pas déplacer une instance d'essai sans frais Spanner. Vous pouvez déplacer l'instance après être passé à une instance payante.
  • Si l'instance utilise le partitionnement géographique, le déplacement de l'instance ne déplace que la partition d'instance par défaut, et non les partitions d'instance supplémentaires.

Considérations sur les performances

Lorsqu'une instance est déplacée, elle subit des latences de lecture/écriture plus élevées et un taux d'abandon de transaction plus élevé. L'utilisation du processeur pendant le déplacement peut atteindre 100 %, car le déplacement de l'instance est effectué à l'aide du processeur de rechange que vous avez provisionné et qui génère du trafic de production. Toutefois, le déplacement d'une instance n'entraîne aucun temps d'arrêt. Le temps nécessaire pour déplacer une instance dépend de plusieurs facteurs, dont la taille des bases de données, le nombre de nœuds et le type de déplacement (par exemple, d'une région à une configuration multirégionale).

Par exemple, pour qu'un déplacement se termine dans les 24 heures, votre instance doit généralement remplir les conditions suivantes avant et pendant le déplacement :

  • Utilisation du CPU – Priorité élevée : moins de 40% dans la configuration de l'instance source. Pour en savoir plus, consultez Utilisation du processeur.
  • Stockage par nœud : moins de 1 tébioctet (Tio) par nœud.

Après le déplacement d'une instance, ses performances varient en fonction des détails de sa configuration. Par exemple, les configurations birégionales et multirégionales ont généralement une latence d'écriture plus élevée et une latence de lecture plus faible que les configurations régionales.

les sauvegardes et les programmations de sauvegardes ;

Lorsque vous déplacez une instance, les sauvegardes et les programmations de sauvegarde de la configuration d'origine de l'instance ne sont pas automatiquement déplacées vers la nouvelle configuration de destination. Le déplacement de l'instance ne démarre pas si des sauvegardes ou des planifications de sauvegarde (y compris les planifications de sauvegarde par défaut) existent sur l'instance lorsque vous lancez le déplacement. Copiez vos sauvegardes et réfléchissez à votre plan de récupération de données avant de déplacer votre instance.

Si vous devez conserver des sauvegardes de la configuration d'origine de l'instance, nous vous recommandons de copier vos sauvegardes sur deux petites instances temporaires (100 PU), placeholder-source et placeholder-dest :

  • placeholder-source : instance avec la même configuration d'instance que la configuration d'origine de l'instance en cours de déplacement. Cela vous permet de restaurer vos sauvegardes dans la configuration d'origine si vous devez annuler le déplacement.

  • placeholder-dest : instance ayant la même configuration d'instance que la configuration d'instance de destination. Cela vous permet de disposer d'une sauvegarde facilement disponible dans la nouvelle configuration immédiatement après la fin du déplacement.

La fonctionnalité de restauration n'est pas compatible avec les restaurations entre configurations. Ces instances d'espace réservé sont donc essentielles pour un rollback ou une récupération rapides dans la nouvelle configuration si nécessaire, ce qui fournit un filet de sécurité en cas de problème avec l'instance déplacée.

Après avoir copié vos sauvegardes dans placeholder-source et placeholder-dest, vous devez supprimer toutes les sauvegardes et planifications de sauvegarde existantes sur l'instance en cours de déplacement avant de pouvoir commencer le déplacement (consultez Copier les sauvegardes dans des instances d'espace réservé et supprimer les sauvegardes et planifications de sauvegarde existantes pour connaître les commandes exactes). Ensuite, une fois le déplacement de l'instance terminé, vous disposez déjà d'une copie de la sauvegarde dans la configuration de destination, et vous pouvez recréer vos planifications de sauvegarde et créer une sauvegarde.

En suivant cette approche, vous assurez la continuité de l'activité et minimisez les temps d'arrêt ou les pertes de données potentiels pendant le processus de déplacement de l'instance.

Déplacer une instance

Vous pouvez déplacer une instance à l'aide de la console Google Cloud ou de la gcloud CLI. Suivez ces quatre phases pour préparer, exécuter, surveiller et finaliser le déplacement de votre instance :

Phase 1 : Préparer votre instance pour le déplacement

Avant de déplacer votre instance, lisez les sections Limites et Considérations sur les performances, puis effectuez chaque étape de cette checklist préalable au déplacement :

  1. Vérifiez les autorisations, l'édition et le quota de destination :

    • Vérifiez que l'opérateur qui effectue le déplacement dispose de l'autorisation IAM spanner.instances.update sur l'instance en cours de déplacement.
    • Vérifiez que votre projet dispose d'un quota de nœuds suffisant dans la configuration de l'instance de destination pour prendre en charge la capacité maximale. Pour en savoir plus, consultez Quotas et limites de Spanner.
    • Si vous déplacez une instance de l'édition Standard d'une configuration régionale vers une configuration birégionale ou multirégionale, passez d'abord à l'édition Enterprise Plus.

  2. Valider l'état de la charge de travail, planifier l'emplacement du client et effectuer des tests dans un environnement hors production :

    • Déplacez d'abord une instance hors production (par exemple, de test ou de préproduction) qui reflète votre instance de production pour estimer la durée du déplacement et observer l'effet sur les performances de votre charge de travail.
    • Vérifiez qu'il n'y a pas de hotspots dans vos bases de données à l'aide de Key Visualizer. La résolution des hotspots avant le déplacement permet d'éviter une latence élevée et l'abandon des transactions pendant la copie des données.
    • Si votre configuration de destination a une région principale par défaut différente de celle de la source, votre latence d'écriture peut augmenter après le déplacement. Pour éviter cela, prévoyez de déployer ou d'acheminer vos applications clientes à forte intensité d'écriture dans la région leader de destination ou à proximité.

  3. Passer de l'autoscaling géré à l'allocation et à la taille manuelles pour le déplacement :

    • Pour que le déplacement se termine dans les 24 heures et pour minimiser l'impact sur la latence, provisionnez une capacité de calcul suffisante afin que l'utilisation maximale du processeur à priorité élevée soit inférieure à 40% et que le stockage par nœud soit inférieur à 1 Tio pendant le déplacement. Consultez les graphiques Utilisation du processeur et Espace de stockage total dans System Insights pour déterminer le nombre de nœuds nécessaires pour votre charge de travail de pointe. Comme Spanner utilise le processeur de réserve pour déplacer les données, l'augmentation de la capacité de calcul accélère le déplacement de l'instance. Vous pouvez confirmer la capacité de calcul idéale pour votre charge de travail en testant la migration dans un environnement de préproduction ou de préproduction.

    • Si l'autoscaler géré est activé sur l'instance, vous devez basculer l'instance sur l'allocation manuelle avant de commencer le déplacement, en utilisant le nombre de nœuds que vous avez déterminé comme nécessaire pour maintenir l'utilisation maximale du processeur à priorité élevée en dessous de 40%:

      gcloud spanner instances update INSTANCE_ID \
  --nodes=PEAK_NODES

  4. Copier les sauvegardes dans des instances d'espace réservé, et supprimer les sauvegardes et les planifications de sauvegarde existantes :

    • Créez les instances placeholder-source et placeholder-dest temporaires décrites dans la section Sauvegardes et programmations de sauvegarde, puis copiez-y vos sauvegardes critiques à l'aide de la commande gcloud spanner backups copy :

      gcloud spanner backups copy \
  --source-instance=INSTANCE_ID \
  --source-backup=SOURCE_BACKUP_ID \
  --destination-instance=PLACEHOLDER_INSTANCE_ID \
  --destination-backup=DESTINATION_BACKUP_ID \
  --expiration-date=EXPIRATION_DATE

    • Vérifiez que toutes les opérations de copie de sauvegarde sur les instances d'espace réservé sont terminées avant de supprimer les sauvegardes sur l'instance en cours de déplacement :

      gcloud spanner operations list \
  --instance=PLACEHOLDER_INSTANCE_ID \
  --type=BACKUP

    • Supprimez toutes les sauvegardes existantes et toutes les planifications de sauvegarde sur chaque base de données de l'instance à déplacer :

      gcloud spanner backups delete BACKUP_ID \
  --instance=INSTANCE_ID

      gcloud spanner backup-schedules delete SCHEDULE_ID \
  --instance=INSTANCE_ID \
  --database=DATABASE_ID

  5. Exporter les tags Data Catalog, suspendre l'automatisation et figer les modifications d'instance et de schéma :

    • Le déplacement d'une instance supprime tous les tags d'instance que vous avez créés dans Data Catalog. Exportez vos tags avant le déplacement pour pouvoir les importer ensuite. Pour en savoir plus, consultez Exporter et importer des tags.
    • Vérifiez vos workflows CI/CD, vos jobs planifiés ou vos dépôts GitOps pour identifier les pipelines d'infrastructure automatisés (comme les exécutions terraform apply --auto-approve planifiées) qui gèrent vos ressources Spanner, et suspendez-les pour éviter tout conflit avec le déplacement en cours.
    • Informez votre organisation que les modifications d'instance et de schéma (y compris les mises à jour du nombre de nœuds, les mises à jour LDD, la création ou la suppression de bases de données et les opérations de sauvegarde) doivent être suspendues jusqu'à la fin du déplacement.

  6. Bases de données avec CMEK activées uniquement : vérifiez les régions de destination et les clés Cloud Key Management Service (Cloud KMS) :

    • Inspectez la configuration de l'instance de destination pour identifier toutes les régions constitutives en lecture/écriture, en lecture seule et témoins :

      gcloud spanner instance-configs describe TARGET_CONFIG

    • Assurez-vous d'avoir provisionné des clés Cloud KMS dans chaque région de la configuration de destination et d'avoir attribué le rôle IAM (Identity and Access Management) roles/cloudkms.cryptoKeyEncrypterDecrypter sur chaque clé cible à l'agent de service Spanner.

Si votre instance respecte ces consignes préalables au déplacement, celui-ci s'effectue généralement dans un délai de 24 heures. Selon la taille de la base de données et la charge de travail de l'application, le temps d'exécution peut être plus ou moins long.

Phase 2 : Démarrer le déplacement de l'instance

Console Google Cloud

  1. Accédez à la page Instances de la console Google Cloud .

    Instances

  2. Sélectionnez l'instance que vous souhaitez déplacer.

  3. Sur la page Vue d'ensemble de l'instance, à côté de Configuration, cliquez sur Déplacer l'instance vers une nouvelle configuration.

  4. Dans le volet Déplacer la base de données vers une nouvelle configuration, sélectionnez la nouvelle configuration d'instance pour votre instance.

  5. Cliquez sur Enregistrer.

gcloud CLI

Utilisez la commande gcloud spanner instances move pour déplacer l'instance.

gcloud spanner instances move INSTANCE_ID \
--target-config=TARGET_CONFIG

Remplacez les éléments suivants :

  • INSTANCE_ID : identifiant permanent de l'instance que vous souhaitez déplacer.
  • TARGET_CONFIG : identifiant permanent de la configuration d'instance vers laquelle vous souhaitez déplacer votre instance. Nouvel emplacement géographique de votre instance. Il peut s'agir d'une configuration d'instance régionale, birégionale ou multirégionale (par exemple, nam3, regional-us-central1 ou custom-nam3-us-west2).

Par exemple, pour déplacer votre instance test-instance de sa configuration d'instance actuelle vers nam3, exécutez la commande suivante :

  gcloud spanner instances move test-instance --target-config=nam3

Facultatif : Si vous souhaitez ajouter une instance répliquée avec accès en lecture seule dans la région us-west2 à la configuration de l'instance de base dans nam3, procédez comme suit :

  1. Clonez la configuration de base et ajoutez l'instance répliquée en lecture seule à la nouvelle configuration d'instance personnalisée custom-nam3-us-west2 :

    gcloud spanner instance-configs create custom-nam3-us-west2 \
--clone-config=nam3 --add-replicas=location=us-west2, type=READ_ONLY

  2. Déplacez votre instance test-instance de sa configuration actuelle vers cette nouvelle configuration d'instance custom-nam3-us-west2 :

    gcloud spanner instances move test-instance --target-config=custom-nam3-us-west2

Facultatif : Déplacer une instance avec des bases de données compatibles avec les CMEK

Avant de déplacer une instance avec des bases de données compatibles avec les CMEK, lisez les remarques d'utilisation suivantes :

  • Si l'instance que vous souhaitez déplacer contient plusieurs bases de données pour lesquelles les CMEK sont activées, vous devez spécifier --target-database-move-configs pour chacune d'elles. Vous pouvez utiliser les mêmes clés pour chaque base de données, mais vous devez spécifier les clés pour chaque base de données compatible avec les CMEK.
  • Vos clés doivent couvrir toutes les régions de la configuration de l'instance de destination, et l'agent de service Spanner doit disposer du rôle IAM roles/cloudkms.cryptoKeyEncrypterDecrypter sur chaque clé cible. Par exemple, si la configuration de votre instance de destination se trouve dans nam3, vous devez définir des clés dans us-east4, us-east1 et us-central1.
  • Vous ne pouvez pas définir de clés Cloud KMS pour les bases de données qui n'utilisent pas de CMEK lors du déplacement de l'instance.
  • Ne désactivez pas, ne détruisez pas, ne remplacez pas et ne révoquez pas les autorisations IAM sur les clés CMEK dans la configuration de l'instance source ou de destination pendant le déplacement de l'instance. Cela interrompt le déplacement et peut bloquer l'accès à la base de données.

Utilisez la commande gcloud spanner instances move pour déplacer une instance avec des bases de données compatibles avec les CMEK. Vous devez inclure l'option --target-database-move-configs et les valeurs de clé Cloud KMS dans la commande, ou configurer un fichier JSON ou YAML avec les clés Cloud KMS nécessaires :

gcloud spanner instances move INSTANCE_ID \
  --target-config=TARGET_CONFIG \
  --target-database-move-configs=^:^database-id=DATABASE_ID_1:kms-key-names=KMS_KEY_1[, KMS_KEY_2 ... ] \
  [--target-database-move-configs=^:^database-id=DATABASE_ID_2:kms-key-names=KMS_KEY_1 ... ]

ou

gcloud spanner instances move INSTANCE_ID \
  --target-config=TARGET_CONFIG \
  --target-database-move-configs=CONFIG_FILE_PATH

Configurez le fichier CONFIG_FILE_PATH avec vos ID de base de données et vos clés Cloud KMS. L'exemple de fichier de configuration suivant contient les clés Cloud KMS de deux bases de données, database-1 et database-2, avec les mêmes clés dans us-east4, us-east1 et us-central1 pour couvrir toutes les régions de nam3 :

[
  {
    "database-id": "database-1",
    "kms-key-names": "projects/PROJECT_ID/locations/us-east4/keyRings/KEY_RING/cryptoKeys/KEY_NAME,projects/PROJECT_ID/locations/us-east1/keyRings/KEY_RING/cryptoKeys/KEY_NAME,projects/PROJECT_ID/locations/us-central1/keyRings/KEY_RING/cryptoKeys/KEY_NAME"
  },
  {
    "database-id": "database-2",
    "kms-key-names": "projects/PROJECT_ID/locations/us-east4/keyRings/KEY_RING/cryptoKeys/KEY_NAME,projects/PROJECT_ID/locations/us-east1/keyRings/KEY_RING/cryptoKeys/KEY_NAME,projects/PROJECT_ID/locations/us-central1/keyRings/KEY_RING/cryptoKeys/KEY_NAME"
  }
]

Phase 3 : Surveiller le déplacement de l'instance

Vous pouvez utiliser gcloud spanner operations describe et un tableau de bord Cloud Monitoring personnalisé pour surveiller la progression du déplacement ou de l'annulation d'une instance.

Afficher la progression des opérations de déplacement et d'annulation

Pour suivre la progression d'une opération de déplacement d'instance ou d'annulation de déplacement d'instance, utilisez la commande gcloud spanner operations describe. Cette commande nécessite l'ID de l'opération de déplacement d'instance en cours.

  1. Obtenez l'ID d'opération de votre opération de déplacement d'instance en exécutant la commande suivante :

    gcloud spanner operations list --instance="INSTANCE_ID"

    Remplacez les éléments suivants :

    • INSTANCE_ID : identifiant permanent de l'instance que vous souhaitez déplacer.

    Le résultat affiche une liste d'opérations de longue durée, y compris l'opération de déplacement d'instance.

  2. Exécutez la commande gcloud spanner operations describe pour afficher le pourcentage de progression et l'état :

    gcloud spanner operations describe OPERATION_ID --instance=INSTANCE_ID

    Remplacez les éléments suivants :

    • OPERATION_ID : ID de l'opération de déplacement d'instance que vous souhaitez vérifier.
    • INSTANCE_ID : ID de l'instance que vous souhaitez vérifier.

Surveiller une opération de déplacement d'instance

Vous pouvez créer un tableau de bord Cloud Monitoring personnalisé pour afficher et surveiller les métriques pendant le déplacement de l'instance, une opération de longue durée qui peut avoir des conséquences sur le service.

Les graphiques Espace de stockage total et Espace de stockage total de la base de données par bases de données du tableau de bord sont utiles pour surveiller la progression du déplacement. Vous pouvez voir l'espace de stockage de la configuration source diminuer progressivement, tandis que celui de la configuration de destination augmente.

Console Google Cloud

  1. Téléchargez le fichier move-instance-dashboard.json. Ce fichier contient les informations nécessaires pour remplir un tableau de bord personnalisé dans Monitoring.

  2. Dans la console Google Cloud , accédez à la page  Tableaux de bord :

    Accéder à la page Tableaux de bord

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

  3. Sur la page Dashboards Overview (Aperçu des tableaux de bord), cliquez sur Create dashboard (Créer un tableau de bord).
  4. Dans la barre d'outils du tableau de bord, cliquez sur le menu déroulant Paramètres du tableau de bord. Sélectionnez ensuite JSON, puis Éditeur JSON.
  5. Dans le volet Éditeur JSON, copiez le contenu du fichier move-instance-dashboard.json que vous avez téléchargé et collez-le dans l'éditeur.
  6. Pour appliquer vos modifications au tableau de bord, cliquez sur Appliquer les modifications. Si vous ne souhaitez pas utiliser ce tableau de bord, revenez à la page de présentation des tableaux de bord.
  7. Une fois le tableau de bord créé, cliquez sur Ajouter un filtre. Sélectionnez ensuite project_id ou instance_id pour surveiller la progression du déplacement de votre instance.

gcloud CLI

  1. Téléchargez le fichier move-instance-dashboard.json. Ce fichier contient les informations nécessaires pour remplir un tableau de bord personnalisé dans Monitoring.

  2. Pour créer un tableau de bord dans un projet, utilisez la commande gcloud monitoring dashboards create :

    gcloud monitoring dashboards create --config-from-file=move-instance-dashboard.json

    Pour en savoir plus, consultez la documentation de référence sur gcloud monitoring dashboards create.

Phase 4 : Effectuer les tâches post-migration

Une fois l'opération de déplacement de longue durée terminée (done: true), suivez la checklist post-déplacement ci-dessous pour restaurer votre configuration opérationnelle :

  1. Réactivez l'autoscaler géré : si vous êtes passé de l'autoscaling géré à l'allocation manuelle avant le déplacement, réactivez l'autoscaler géré avec vos limites de capacité de calcul minimale et maximale (par exemple, en exécutant gcloud spanner instances update INSTANCE_ID avec vos options d'autoscaling ou dans la console Google Cloud ).
  2. Recréer des programmations de sauvegarde et créer une sauvegarde : recréez vos programmations de sauvegarde et créez une sauvegarde pour vos bases de données dans la configuration de l'instance de destination.
  3. Importer des tags Data Catalog : si vous avez exporté des tags Data Catalog avant le déplacement, réimportez-les dans votre instance déplacée.
  4. Mettez à jour les configurations d'automatisation, l'emplacement du client et les charges de travail en aval :
    • Si vous gérez vos ressources Spanner à l'aide d'outils d'automatisation tels que Terraform, mettez à jour vos fichiers de configuration pour refléter la nouvelle configuration de l'instance de destination avant de réactiver les déploiements automatisés.
    • Si votre région principale a changé après le déplacement, déployez ou acheminez vos applications clientes dans ou à proximité de la nouvelle région principale (ou modifiez la région principale par défaut de la base de données si vous utilisez une configuration birégionale ou multirégionale) pour réduire la latence d'écriture, et vérifiez la connectivité et la latence entre les applications et les pipelines en aval.
  5. Supprimer les instances d'espace réservé temporaires : après avoir vérifié votre instance déplacée et créé des sauvegardes dans la configuration de destination, supprimez les instances temporaires placeholder-source et placeholder-dest si vous n'avez plus besoin des sauvegardes copiées.

Annuler le déplacement d'une instance

Vous ne pouvez annuler un déplacement d'instance que s'il est toujours en cours. Si vous souhaitez annuler un déplacement d'instance déjà terminé, vous devez lancer un nouveau déplacement.

Vous pouvez utiliser gcloud spanner operations cancel pour annuler les opérations de déplacement d'instance. L'annulation n'est pas instantanée et prend à peu près le même temps que celui écoulé depuis le début du déplacement. Cela est dû au fait que les données doivent être déplacées vers la configuration de l'instance source.

Cette commande nécessite l'ID de l'opération de déplacement d'instance en cours.

  1. Obtenez l'ID de l'opération en exécutant la commande suivante :

    gcloud spanner operations list --type=INSTANCE --instance="INSTANCE_ID"
--filter="done:False AND metadata.@type:MoveInstanceMetadata"

    Remplacez les éléments suivants :

    • INSTANCE_ID : identifiant permanent de l'instance que vous souhaitez déplacer.

    Le résultat affiche une liste des opérations de déplacement d'instance en cours.

  2. Exécutez la commande gcloud spanner operations cancel pour annuler le déplacement de l'instance :

    gcloud spanner operations cancel OPERATION_ID

    Remplacez les éléments suivants :

    • OPERATION_ID : ID de l'opération de déplacement d'instance que vous souhaitez annuler.

Étapes suivantes