Créer un job de migration vers un cluster de destination existant

Lorsque vous effectuez une migration vers un cluster AlloyDB pour PostgreSQL de destination existant, Database Migration Service rétrograde le cluster de destination pour le configurer en tant qu'instance répliquée externe. La rétrogradation d'un cluster ne place pas AlloyDB pour PostgreSQL en mode lecture seule, mais l'exécution de certaines opérations pendant le processus de migration peut entraîner des erreurs de migration. Lorsque vous migrez vers un cluster de destination existant, tenez compte des considérations opérationnelles suivantes :
  • Rétrogradation du cluster : Database Migration Service rétrograde le cluster de destination pour le configurer en tant qu'instance répliquée de la base de données source.
  • Évitez les opérations d'écriture sur les données en cours de migration : n'effectuez pas d'opérations d'écriture (telles que INSERT, UPDATE, DELETE ou des modifications de schéma LDD) dans le cluster de destination sur les tables ou les bases de données incluses dans la migration. Ces opérations peuvent entraîner des conflits de réplication avec les données provenant de la source.
  • Gérer les utilisateurs de la base de données : vous pouvez créer et gérer des utilisateurs de la base de données à tout moment à l'aide de commandes psql standards ou via AlloyDB pour PostgreSQL dans la console Google Cloud . Pour en savoir plus, consultez Gérer les utilisateurs de base de données dans la documentation AlloyDB pour PostgreSQL.

Pour en savoir plus, consultez Limites connues pour les clusters de destination existants.

Database Migration Service utilise des jobs de migration pour migrer des données de votre base de données source vers le cluster AlloyDB pour PostgreSQL de destination. La création d'un job de migration pour un cluster de destination existant comprend les étapes suivantes :

  • Définir les paramètres du job de migration
  • Définir les paramètres de la source et sélectionner les bases de données à migrer
  • Sélectionner le cluster AlloyDB pour PostgreSQL de destination existant
  • Rétrogradation du cluster existant pour le configurer en tant qu'instance répliquée de la base de données source
  • Configurer la connectivité entre les bases de données source et de destination
  • Tester le job de migration pour vous assurer que les informations de connexion fournies sont valides

Avant de commencer

Avant de créer un job de migration vers un cluster AlloyDB pour PostgreSQL de destination existant, assurez-vous d'effectuer les opérations suivantes :

  1. Vérifiez que ce type de migration est compatible avec votre scénario. Par exemple, lorsque vous souhaitez migrer vers un cluster créé en dehors de Database Migration Service, le cluster de destination AlloyDB pour PostgreSQL doit être vide ou ne contenir que des données de configuration système. Pour plus d'informations, reportez-vous aux limites connues.

  2. Créez le cluster AlloyDB pour PostgreSQL de destination et son instance principale. Consultez Créer un cluster et son instance principale dans la documentation AlloyDB pour PostgreSQL.

  3. Préparez votre instance de base de données source. Consultez les pages suivantes :
    1. Configurer la base de données source
    2. Créer le profil de connexion source
    3. Configurer la connectivité

Pour créer un job de migration vers un cluster de destination existant, procédez comme suit :

Console

Définir les paramètres du job de migration

  1. Dans la console Google Cloud , accédez à la page Jobs de migration.

    Accéder à la page "Jobs de migration"

  2. Cliquez sur Créer un job de migration.

    La page de l'assistant de configuration du job de migration s'ouvre. Cet assistant contient plusieurs panneaux qui vous guident à travers chaque étape de configuration.

    Vous pouvez suspendre la création d'un job de migration à tout moment en cliquant sur Enregistrer et quitter. Toutes les données que vous saisissez jusqu'à ce point sont enregistrées dans un job de migration brouillon. Vous pouvez terminer votre brouillon de job de migration plus tard.

  3. Sur la page Premiers pas, saisissez les informations suivantes :
    1. Nom de la tâche de migration

      Il s'agit d'un nom lisible par l'humain pour votre job de migration. Cette valeur s'affiche dans la console Google Cloud .

    2. ID du job de migration

      Il s'agit d'un identifiant lisible par machine pour votre job de migration. Vous utilisez cette valeur pour travailler avec des jobs de migration à l'aide des commandes de la Google Cloud CLI ou de l'API Database Migration Service.

    3. Dans la liste Moteur de base de données source, sélectionnez PostgreSQL.
    4. Dans la liste Moteur de base de données de destination, sélectionnez AlloyDB pour PostgreSQL.
    5. Sélectionnez la région dans laquelle vous enregistrez le job de migration.

      Database Migration Service est un produit entièrement régional, ce qui signifie que toutes les entités liées à votre migration (profils de connexion source et de destination, jobs de migration, clusters de destination) doivent être enregistrées dans une seule région. Sélectionnez la région où se trouve votre cluster de destination existant. Une fois que vous avez choisi la région de destination, vous ne pouvez plus la modifier.

    6. Sélectionnez Continu (instantané et modifications en cours) comme type de mission de migration. Les migrations homogènes vers AlloyDB pour PostgreSQL ne sont compatibles qu'avec les migrations continues.
  4. Cliquez sur Enregistrer et continuer.

Spécifier des informations sur le profil de connexion source

Sur la page Définir une source, procédez comme suit :

  1. Dans le menu déroulant Profil de connexion source, sélectionnez le profil de connexion de votre base de données source.
  2. Dans la section Personnaliser les configurations de parallélisme, cliquez sur Afficher les configurations de parallélisme.

    Lors du vidage complet initial, l'extension pglogical réplique les données au niveau de la table et ne divise pas une table non partitionnée, une partition feuille ou une table sans clé primaire entre plusieurs abonnements. Cela signifie que le parallélisme amélioré du vidage de données ne peut pas augmenter la vitesse de vidage initiale pour une seule grande table non partitionnée, car cette table est copiée dans un seul abonnement. Pour en savoir plus, consultez Remarques sur le parallélisme des vidages de données.

    La vitesse du parallélisme du vidage des données est liée à la quantité de charge induite sur votre base de données source :

    • Optimal (recommandé) : performances équilibrées avec une charge optimale sur la base de données source. Database Migration Service crée jusqu'à deux abonnements par base de données (jusqu'à deux au total pour toutes les bases de données, avec au moins un abonnement par base de données migrée).
    • Maximum : fournit les vitesses de vidage les plus élevées, mais peut entraîner une charge accrue sur la base de données source. Database Migration Service crée jusqu'à quatre abonnements par base de données (jusqu'à quatre au total pour toutes les bases de données, avec au moins un abonnement par base de données migrée).
    • Minimum : utilise la plus faible quantité de ressources de calcul sur la base de données source, mais peut avoir un débit de vidage plus lent. Database Migration Service crée un abonnement par base de données.

    Si vous choisissez des paramètres de parallélisme de vidage des données ajustés, veillez à augmenter les paramètres max_replication_slots, max_wal_senders et max_worker_processes sur votre base de données source.

  3. Cliquez sur Enregistrer et continuer.

Sélectionner le cluster AlloyDB pour PostgreSQL de destination

  1. Dans le menu Type d'instance de destination, sélectionnez Cluster existant.
  2. Dans la section Sélectionner un cluster de destination, sélectionnez votre cluster AlloyDB pour PostgreSQL de destination.

  3. Examinez les informations de la section Détails du cluster, puis cliquez sur Sélectionner et continuer.

    Pour migrer vers une base de données de destination existante, Database Migration Service rétrograde le cluster cible et le configure en tant qu'instance répliquée. Pour indiquer que la rétrogradation peut être effectuée en toute sécurité, saisissez l'identifiant du cluster de destination dans la fenêtre de confirmation.

  4. Cliquez sur Confirmer et continuer.

Configurer la connectivité entre l'instance de base de données source et le cluster de destination

Dans le menu déroulant Méthode de connectivité, sélectionnez une méthode de connectivité réseau. Cette méthode définit la manière dont le cluster AlloyDB pour PostgreSQL de destination se connecte à la base de données source. Les méthodes de connectivité réseau actuelles incluent la liste d'autorisation d'adresses IP, le tunnel SSH inversé, les interfaces Private Service Connect, l'appairage de VPC et le proxy TCP via une VM hébergée dans le cloud.

Si vous souhaitez utiliser…Alors…
La méthode de connectivité réseau par liste d'autorisation d'adresses IP Copiez les deux adresses IP publiques sortantes de l'instance principale de votre cluster de destination et utilisez-les pour configurer le pare-feu réseau de votre serveur de base de données source et dans le fichier pg_hba.conf.
La méthode de connectivité réseau par tunnel SSH inversé Sélectionnez l'instance de VM Compute Engine qui hébergera le tunnel.

Après avoir spécifié l'instance, Google fournit un script qui effectue les étapes de configuration du tunnel entre les bases de données source et de destination. Exécutez le script dans Google Cloud CLI à partir d'une machine connectée à la base de données source et à Google Cloud.
La méthode de connectivité des interfaces Private Service Connect, Database Migration Service établit automatiquement les connexions requises. Cette méthode de connectivité n'est disponible que si vous disposez d'un cluster de destination compatible avec Private Service Connect et doté d'un rattachement de réseau. Pour en savoir plus sur Private Service Connect, consultez Configurer Private Service Connect dans la documentation AlloyDB pour PostgreSQL.
La méthode de connectivité réseau par appairage de VPC Sélectionnez le réseau VPC qui héberge la base de données source. Le cluster AlloyDB pour PostgreSQL se connecte à ce réseau à l'aide de l'accès aux services privés.
La méthode de connectivité par proxy TCP via une VM hébergée dans le cloud Saisissez les informations requises pour la nouvelle instance de VM Compute Engine qui hébergera le proxy TCP.

Une fois les détails spécifiés, la console Google Cloud fournit un script qui configure le proxy entre les bases de données source et de destination. Exécutez le script sur une machine disposant d'une version à jour de la Google Cloud CLI.

Après avoir exécuté le script, saisissez l'adresse IP privée de la VM que vous venez de créer, puis cliquez sur Configurer et continuer.

Après avoir sélectionné et configuré la connectivité réseau, cliquez sur Configurer et continuer.

Configurer des bases de données de migration

Vous pouvez migrer toutes les bases de données de votre instance source ou n'en choisir que certaines.

  1. Dans la liste Bases de données à migrer, sélectionnez l'une des options suivantes :
    • Toutes les bases de données : sélectionne toutes les bases de données existantes sur la source.
    • Bases de données spécifiques : permet de sélectionner des bases de données spécifiques parmi toutes les bases de données existantes sur la source.

  2. Si vous souhaitez migrer des bases de données spécifiques, filtrez la liste qui s'affiche et sélectionnez les bases de données que vous souhaitez que Database Migration Service migre vers votre destination.

    Si la liste ne s'affiche pas et qu'une erreur de découverte de base de données s'affiche, cliquez sur Actualiser. Si la découverte de la base de données échoue, le job migre toutes les bases de données. Vous pouvez continuer à créer un job de migration et corriger les erreurs de connectivité plus tard.

  3. Cliquez sur Enregistrer et continuer.

Tester, créer et exécuter le job de migration

Lors de cette dernière étape, examinez le récapitulatif des paramètres du job de migration, de la source, de la destination et de la méthode de connectivité, puis testez la validité de la configuration du job de migration. En cas de problème, vous pouvez modifier les paramètres du job de migration. Tous les paramètres ne sont pas modifiables.

  1. Sur la page Tester et créer le job de migration, cliquez sur Tester le job.

    Si le test échoue, résolvez le problème dans la partie appropriée du flux, puis revenez au test. Pour en savoir plus sur la résolution des problèmes liés à un échec de test de job de migration, consultez Diagnostiquer les problèmes pour AlloyDB pour PostgreSQL.

  2. Une fois le test du job de migration terminé, cliquez sur Créer et démarrer le job pour créer le job de migration et le démarrer immédiatement, ou sur Créer le job pour créer le job de migration sans le démarrer immédiatement.

    Si le job n'est pas démarré au moment de sa création, vous pouvez le démarrer depuis la page Jobs de migration en cliquant sur Démarrer. Quelle que soit la date de début du job de migration, votre organisation est facturée pour l'existence du cluster de destination.

    Votre migration est en cours. Lorsque vous démarrez le job de migration, Database Migration Service lance le vidage complet initial et la réplication continue. Pour en savoir plus, consultez Limites connues.

  3. Passez à l'étape Examiner le job de migration.

Google Cloud CLI

Lorsque vous effectuez une migration vers un cluster existant à l'aide de la Google Cloud CLI, vous devez créer manuellement le profil de connexion pour le cluster de destination. Cela n'est pas nécessaire lorsque vous utilisez la console Google Cloud , car Database Migration Service se charge de créer et de supprimer le profil de connexion de destination pour vous.

  1. Créez le profil de connexion de destination.
    Créez le profil de connexion de destination pour votre cluster de destination existant en exécutant la commande gcloud database-migration connection-profiles create (cliquez sur le lien pour la développer) :

    gcloud database-migration connection-profiles create postgresql

    Cet exemple utilise l'option facultative --no-async pour que toutes les opérations soient effectuées de manière synchrone. Cela signifie que l'exécution de certaines commandes peut prendre un certain temps. Vous pouvez ignorer l'option --no-async pour exécuter des commandes de manière asynchrone. Si vous le faites, vous devez utiliser la commande gcloud database-migration operations describe pour vérifier si l'opération a réussi.

    Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

    • DEST_CONN_ID par l'identifiant du profil de connexion de destination.
    • REGION par la région dans laquelle vous souhaitez enregistrer le profil de connexion. Cette région doit être identique à celle de votre cluster de destination.
    • DEST_CLUSTER par l'ID de votre cluster AlloyDB pour PostgreSQL de destination précréé.
    • DEST_USER par le nom de l'utilisateur de migration sur votre base de données de destination.
    • DEST_PASSWORD par le mot de passe de l'utilisateur de migration dans la base de données de destination.

    Exécutez la commande suivante :

    Linux, macOS ou Cloud Shell

    gcloud database-migration connection-profiles create postgresql DEST_CONN_ID \
  --region=REGION \
  --alloydb-cluster=DEST_CLUSTER \
  --username=DEST_USER \
  --password=DEST_PASSWORD \
  --role=DESTINATION \
  --no-async

    Windows (PowerShell)

    gcloud database-migration connection-profiles create postgresql DEST_CONN_ID `
  --region=REGION `
  --alloydb-cluster=DEST_CLUSTER `
  --username=DEST_USER `
  --password=DEST_PASSWORD `
  --role=DESTINATION `
  --no-async

    Windows (cmd.exe)

    gcloud database-migration connection-profiles create postgresql DEST_CONN_ID ^
  --region=REGION ^
  --alloydb-cluster=DEST_CLUSTER ^
  --username=DEST_USER ^
  --password=DEST_PASSWORD ^
  --role=DESTINATION ^
  --no-async

    Vous devriez obtenir un résultat semblable à celui-ci :

    Waiting for connection profile [DEST_CONN_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created connection profile DEST_CONN_ID [OPERATION_ID]

  2. Créez le job de migration.
    L'exemple suivant représente un scénario de migration dans lequel vous utilisez la connectivité par adresse IP privée entre les bases de données source et de destination. Si vous utilisez un autre type de connectivité (par exemple, une liste d'autorisation d'adresses IP, l'appairage de VPC ou un tunnel SSH inversé), veillez à ajouter les options requises, telles que --static-ip, --peer-vpc ou --vm, --vm-ip, --vm-port et --vpc. Pour en savoir plus, consultez Configurer la connectivité et Exemples Google Cloud CLI.
    Exécutez la commande suivante (cliquez sur le lien pour développer) :

    gcloud database-migration migration-jobs create

    Cet exemple utilise l'option facultative --no-async pour que toutes les opérations soient effectuées de manière synchrone. Cela signifie que l'exécution de certaines commandes peut prendre un certain temps. Vous pouvez ignorer l'option --no-async pour exécuter des commandes de manière asynchrone. Si vous le faites, vous devez utiliser la commande gcloud database-migration operations describe pour vérifier si l'opération a réussi.

    Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

    • MIGRATION_JOB_ID par un identifiant lisible par machine pour votre job de migration. Vous utilisez cette valeur pour travailler avec des jobs de migration à l'aide des commandes de la Google Cloud CLI ou de l'API Database Migration Service.
    • REGION par l'identifiant de la région dans laquelle vous souhaitez enregistrer le job de migration.
    • MIGRATION_JOB_NAME par un nom lisible par l'humain pour votre job de migration. Cette valeur s'affiche dans Database Migration Service dans la console Google Cloud .
    • SOURCE_CONNECTION_PROFILE_ID par un identifiant lisible par machine du profil de connexion source. Pour en savoir plus, consultez Créer un profil de connexion source.
    • DESTINATION_CONNECTION_PROFILE_ID par un identifiant lisible par machine du profil de connexion de destination.

    • Facultatif : Par défaut, Database Migration Service migre toutes les bases de données de votre source. Si vous ne souhaitez migrer que des bases de données spécifiques, utilisez l'option --databases-filter et spécifiez leurs identifiants sous la forme d'une liste d'éléments séparés par une virgule.

      Par exemple : --databases-filter=my-business-database,my-other-database

      Vous pourrez modifier ultérieurement les jobs de migration que vous avez créés avec l'option --databases-filter à l'aide de la commande gcloud database-migration migration-jobs update.

    Exécutez la commande suivante :

    Linux, macOS ou Cloud Shell

    gcloud database-migration migration-jobs \
create MIGRATION_JOB_ID \
  --no-async \
  --region=REGION \
  --display-name=MIGRATION_JOB_NAME \
  --source=SOURCE_CONNECTION_PROFILE_ID \
  --destination=DESTINATION_CONNECTION_PROFILE_ID \
  --type=CONTINUOUS

    Windows (PowerShell)

    gcloud database-migration migration-jobs `
create MIGRATION_JOB_ID `
  --no-async `
  --region=REGION `
  --display-name=MIGRATION_JOB_NAME `
  --source=SOURCE_CONNECTION_PROFILE_ID `
  --destination=DESTINATION_CONNECTION_PROFILE_ID `
  --type=CONTINUOUS

    Windows (cmd.exe)

    gcloud database-migration migration-jobs ^
create MIGRATION_JOB_ID ^
  --no-async ^
  --region=REGION ^
  --display-name=MIGRATION_JOB_NAME ^
  --source=SOURCE_CONNECTION_PROFILE_ID ^
  --destination=DESTINATION_CONNECTION_PROFILE_ID ^
  --type=CONTINUOUS

    Vous devriez obtenir un résultat semblable à celui-ci :

    Waiting for migration job [MIGRATION_JOB_ID]
to be created with [OPERATION_ID]

Waiting for operation [OPERATION_ID] to complete...done.

Created migration job MIGRATION_JOB_ID [OPERATION_ID]

  3. Rétrogradez la base de données de destination.
    Database Migration Service nécessite que vous rétrogradiez le cluster de destination existant pour le configurer en tant qu'instance répliquée externe avant de démarrer le job de migration. Exécutez la commande gcloud database-migration migration-jobs demote-destination (cliquez sur le lien pour la développer) :

    gcloud database-migration migration-jobs demote-destination

    Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

    • MIGRATION_JOB_ID par l'identifiant de votre job de migration.

      Si vous ne connaissez pas l'identifiant, vous pouvez utiliser la commande gcloud database-migration migration-jobs list pour lister tous les jobs de migration d'une région donnée et afficher leurs identifiants.

    • REGION par l'identifiant de la région dans laquelle votre job de migration est enregistré.

    Exécutez la commande suivante :

    Linux, macOS ou Cloud Shell

    gcloud database-migration migration-jobs \
demote-destination MIGRATION_JOB_ID \
  --region=REGION

    Windows (PowerShell)

    gcloud database-migration migration-jobs `
demote-destination MIGRATION_JOB_ID `
  --region=REGION

    Windows (cmd.exe)

    gcloud database-migration migration-jobs ^
demote-destination MIGRATION_JOB_ID ^
  --region=REGION

    Résultat

    L'action est effectuée de manière asynchrone. Cette commande renvoie donc une entité Operation qui représente une opération de longue durée : 

    done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: demote-destination
name: OPERATION_ID

    Pour vérifier si l'opération a réussi, vous pouvez interroger l'objet d'opération renvoyé ou vérifier l'état du job de migration :

  4. Facultatif : Vérifiez le job de migration.
    À ce stade, votre job de migration est configuré et connecté à votre cluster de destination. Vous pouvez la gérer à l'aide des opérations verify, start, stop, restart et resume. Nous vous recommandons de commencer par vérifier votre job de migration en exécutant la commande gcloud database-migration migration-jobs verify (cliquez sur le lien pour la développer) :

    gcloud database-migration migration-jobs verify

    Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

    • MIGRATION_JOB_ID par l'identifiant de votre job de migration.

      Si vous ne connaissez pas l'identifiant, vous pouvez utiliser la commande gcloud database-migration migration-jobs list pour lister tous les jobs de migration d'une région donnée et afficher leurs identifiants.

    • REGION par l'identifiant de la région dans laquelle votre job de migration est enregistré.

    Exécutez la commande suivante :

    Linux, macOS ou Cloud Shell

    gcloud database-migration migration-jobs \
verify MIGRATION_JOB_ID \
  --region=REGION

    Windows (PowerShell)

    gcloud database-migration migration-jobs `
verify MIGRATION_JOB_ID `
  --region=REGION

    Windows (cmd.exe)

    gcloud database-migration migration-jobs ^
verify MIGRATION_JOB_ID ^
  --region=REGION

    Résultat

    L'action est effectuée de manière asynchrone. Cette commande renvoie donc une entité Operation qui représente une opération de longue durée : 

    done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: verify
name: OPERATION_ID

    Pour vérifier si l'opération a réussi, vous pouvez interroger l'objet d'opération renvoyé ou vérifier l'état du job de migration :

  5. 1. Démarrez le job de migration.
    Démarrez le job de migration en exécutant la commande gcloud database-migration migration-jobs start (cliquez sur le lien pour la développer) :

    gcloud database-migration migration-jobs start

    Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

    • MIGRATION_JOB_ID par l'identifiant de votre job de migration.

      Si vous ne connaissez pas l'identifiant, vous pouvez utiliser la commande gcloud database-migration migration-jobs list pour lister tous les jobs de migration d'une région donnée et afficher leurs identifiants.

    • REGION par l'identifiant de la région dans laquelle votre job de migration est enregistré.

    Exécutez la commande suivante :

    Linux, macOS ou Cloud Shell

    gcloud database-migration migration-jobs \
start MIGRATION_JOB_ID \
  --region=REGION

    Windows (PowerShell)

    gcloud database-migration migration-jobs `
start MIGRATION_JOB_ID `
  --region=REGION

    Windows (cmd.exe)

    gcloud database-migration migration-jobs ^
start MIGRATION_JOB_ID ^
  --region=REGION

    Résultat

    L'action est effectuée de manière asynchrone. Cette commande renvoie donc une entité Operation qui représente une opération de longue durée : 

    done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: start
name: OPERATION_ID

    Pour vérifier si l'opération a réussi, vous pouvez interroger l'objet d'opération renvoyé ou vérifier l'état du job de migration :

  6. Promouvoir le job de migration
    Une fois que la migration atteint la phase de capture des données modifiées (CDC, Change Data Capture), vous pouvez promouvoir le cluster de destination d'une instance répliquée vers un cluster principal autonome. Exécutez la commande gcloud database-migration migration-jobs promote (cliquez sur le lien pour la développer) :

    gcloud database-migration migration-jobs promote

    Avant d'utiliser les données de la commande ci-dessous, effectuez les remplacements suivants :

    • MIGRATION_JOB_ID par l'identifiant de votre job de migration.

      Si vous ne connaissez pas l'identifiant, vous pouvez utiliser la commande gcloud database-migration migration-jobs list pour lister tous les jobs de migration d'une région donnée et afficher leurs identifiants.

    • REGION par l'identifiant de la région dans laquelle votre job de migration est enregistré.

    Exécutez la commande suivante :

    Linux, macOS ou Cloud Shell

    gcloud database-migration migration-jobs \
promote MIGRATION_JOB_ID \
  --region=REGION

    Windows (PowerShell)

    gcloud database-migration migration-jobs `
promote MIGRATION_JOB_ID `
  --region=REGION

    Windows (cmd.exe)

    gcloud database-migration migration-jobs ^
promote MIGRATION_JOB_ID ^
  --region=REGION

    Résultat

    L'action est effectuée de manière asynchrone. Cette commande renvoie donc une entité Operation qui représente une opération de longue durée : 

    done: false
metadata:
  '@type': type.googleapis.com/google.cloud.clouddms.v1.OperationMetadata
  apiVersion: v1
  createTime: '2024-02-20T12:20:24.493106418Z'
  requestedCancellation: false
  target: MIGRATION_JOB_ID
  verb: promote
name: OPERATION_ID

    Pour vérifier si l'opération a réussi, vous pouvez interroger l'objet d'opération renvoyé ou vérifier l'état du job de migration :