Tutoriel : Migrer en ligne à partir d’une machine virtuelle Azure ou d’un serveur PostgreSQL local vers Azure Database pour PostgreSQL avec le service de migration en préversion

Cet article vous montre comment migrer, à l’aide du portail Azure, votre base de données PostgreSQL à partir d’une machine virtuelle Azure ou d’un serveur PostgreSQL local vers une instance d’Azure Database pour PostgreSQL. Le portail Azure vous permet d’effectuer différentes tâches, notamment la migration de base de données. En suivant les étapes décrites dans ce tutoriel, vous pouvez transférer en toute transparence votre base de données vers Azure et tirer parti de sa scalabilité et de ses puissantes fonctionnalités.

Configurer la tâche de migration

Le service de migration inclut une expérience simple basée sur un Assistant sur le Portail Azure. Voici comment procéder :

1. Ouvrez votre navigateur web et accédez au portail. Entrez vos informations d’identification pour vous connecter. Il s’ouvre par défaut sur le tableau de bord des services.

2. Accédez à votre cible Azure Database pour PostgreSQL - Serveur flexible.

3. Dans le menu de gauche de l’onglet Vue d’ensemble du serveur flexible, faites défiler vers le bas jusqu’à Migration et sélectionnez cette option.

   

4. Cliquez sur le bouton Créer pour migrer à partir d’une machine virtuelle Azure ou d’un serveur PostgreSQL local vers le serveur flexible. S’il s’agit de la première fois que vous utilisez le service de migration, une grille vide s’affiche pour vous inviter à commencer votre première migration.

   

   Si vous avez déjà créé des migrations vers le serveur flexible cible, la grille contient des informations sur les tentatives de migration.

5. Cliquez sur le bouton Créer. Vous utilisez ensuite une série d’onglets basée sur un Assistant pour créer une migration vers ce serveur flexible cible à partir de n’importe quelle serveur PostgreSQL source.

Programme d’installation

Le premier onglet est l’onglet de configuration, où l’utilisateur lance les migrations en fournissant des détails de migration tels que le nom de la migration et le type de source.

• Le nom de la migration est l’identificateur unique de chaque migration vers cette cible de serveur flexible. Ce champ accepte uniquement les caractères alphanumériques et n’accepte aucun caractère spécial à l’exception du trait d’union (-). Le nom ne peut pas commencer par un trait d’union et doit être unique pour un serveur cible. Deux migrations vers la même cible de serveur flexible ne peuvent pas avoir le même nom.

• Type de serveur source : en fonction de votre source PostgreSQL, vous pouvez sélectionner Machine virtuelle Azure ou infrastructure locale.

• L’option de migration vous permet d’effectuer des validations avant de déclencher une migration. Vous pouvez choisir l’une des options suivantes :

  • Valider : vérifie la préparation de votre serveur et de votre base de données pour la migration vers la cible.
  • Migrer : ignore les validations et démarre les migrations.
  • Valider et migrer : effectue la validation avant de déclencher une migration. La migration est uniquement déclenchée s’il n’y a pas d’échecs de validation.

Il est toujours recommandé de choisir l’option Valider ou Valider et migrer pour effectuer des validations de prémigration avant d’exécuter la migration. Pour en savoir plus sur la validation de la prémigration, reportez-vous à cette documentation.

Mode de migration vous permet de choisir le mode de la migration. Hors connexion est l’option par défaut.

Sélectionnez le bouton Suivant : Se connecter à la source.

Serveur d’exécution

Le serveur d’exécution de migration est une fonctionnalité spécialisée intégrée au service de migration dans Azure Database pour PostgreSQL, conçu pour agir en tant que serveur intermédiaire pendant la migration. Il s’agit d’une instance de serveur flexible Azure Database pour PostgreSQL distincte qui n’est pas le serveur cible, mais utilisé pour faciliter la migration des bases de données à partir d’un environnement source accessible uniquement via un réseau privé.

Pour plus d’informations sur le serveur d’exécution, visitez la page du Serveur d’exécution de migration.

Se connecter à la source

L’onglet Se connecter à la source vous invite à fournir des informations relatives à la source sélectionnée dans l’onglet Configuration, qui est la source des bases de données.

• Nom du serveur : indiquez le nom d’hôte ou l’adresse IP de l’instance PostgreSQL source
• Port : numéro de port du serveur source
• Nom de connexion de l’administrateur du serveur : nom d’utilisateur du serveur PostgreSQL source
• Mot de passe : mot de passe du serveur PostgreSQL source
• Mode SSL : les valeurs prises en charge sont préférées et requises. Lorsque le protocole SSL sur le serveur PostgreSQL source est DÉSACTIVÉ, utilisez SSLMODE=prefer. Si le protocole SSL sur le serveur source est ACTIVÉ, utilisez SSLMODE=require. Les valeurs SSL peuvent être déterminées dans le fichier postgresql.conf.
• Tester la connexion : effectue le test de connectivité entre la cible et la source. Une fois la connexion établie, les utilisateurs peuvent passer à l’étape suivante. Sinon, vous devez identifier les problèmes de mise en réseau entre la cible et la source et vérifier le nom d’utilisateur et le mot de passe de la source. Il faut quelques minutes pour que le test de connexion établisse une connexion la cible et la source.

Une fois le test de connexion réussi, sélectionnez Suivant : Sélectionner la cible de migration

Sélectionner la cible de migration

L’onglet Sélectionner la cible de migration affiche les métadonnées du serveur flexible cible telles que le nom de l’abonnement, le groupe de ressources, le nom du serveur, l’emplacement et la version PostgreSQL.

• Nom d’utilisateur administrateur : nom d’utilisateur administrateur du serveur PostgreSQL cible
• Mot de passe : mot de passe du serveur PostgreSQL cible
• Tester la connexion : effectue le test de connectivité entre la cible et la source. Une fois la connexion établie, les utilisateurs peuvent passer à l’étape suivante. Sinon, nous devons identifier les problèmes de mise en réseau entre la cible et la source et vérifier le nom d’utilisateur et le mot de passe de la cible. Il faut quelques minutes pour que la connexion de test établisse une connexion entre la cible et la source.

Une fois le test de connexion réussi, sélectionnez le bouton Suivant : Sélectionner la ou les bases de données à migrer.

Sélectionner des bases de données pour la migration

Sous cet onglet, une liste de bases de données utilisateur se trouve à l’intérieur du serveur source sélectionné dans l’onglet de configuration. Vous pouvez sélectionner et migrer jusqu’à huit bases de données en une seule tentative de migration. S’il existe plus de huit bases de données utilisateur, le processus de migration est répété entre les serveurs source et cible pour l’ensemble de bases de données suivant.

Après avoir sélectionné les bases de données, sélectionnez Suivant : Résumé

Résumé

L’onglet Résumé récapitule toutes les informations de la source et de la cible pour la création de la validation ou de la migration. Passez en revue les détails et cliquez sur le bouton Démarrer.

Surveiller la migration

Quelques secondes après avoir cliqué sur le bouton Démarrer, une notification s’affiche pour indiquer que la création de la validation ou de la migration est réussie. Vous êtes ensuite redirigé automatiquement vers la panneau Migration du serveur flexible, qui a une nouvelle entrée pour la validation ou la migration récemment créée.

La grille qui affiche les migrations comporte les colonnes suivantes : Nom, État, Mode de migration, Type de migration, Serveur source, Type de serveur source, Bases de données, **Durée et Heure de début. Les entrées sont affichées dans l’ordre décroissant de l’heure de début avec l’entrée la plus récente en haut. Vous pouvez utiliser le bouton d’actualisation pour actualiser l’état de la validation ou de la migration. Sélectionnez le nom de la migration dans la grille pour afficher les informations associées.

Après la validation ou une fois la migration créée, l’état devient InProgress avec le sous-état PerformingPreRequisiteSteps. Le flux de travail prend 2 à 3 minutes pour configurer l’infrastructure de migration et les connexions réseau.

Détails de la migration

Dans l’onglet Configuration, nous avons défini l’option de migration sur Migrer et valider. Dans ce scénario, les validations sont effectuées en premier avant le début de la migration. Dès que le sous-état PerformingPreRequisiteSteps est terminé, le workflow passe au sous-état Validation en cours.

• Si la validation présente des erreurs, la migration passe à l’état Échec.
• Si la validation se termine sans erreur, la migration démarre et le flux de travail passe au sous-état Migration des données.

Les résultats de la validation sont affichés sous l’onglet Validation et la migration est surveillée sous l’onglet Migration.

Les états de migration possibles incluent :

États de migration

Sous-états de la migration

Sous-états de validation

Basculement

Si les deux options Migrer et Valider et migrer sont présentes, l’exécution de la migration en ligne nécessite une autre étape de la part de l’utilisateur : une action de basculement. Après la copie/le clonage des données de base, la migration passe à l’état WaitingForUserAction et au sous-état `WaitingForCutoverTrigger'. Dans cet état, l’utilisateur peut déclencher le basculement à partir du portail en sélectionnant la migration.

Avant de lancer le basculement, il est important de s’assurer que :

• Les écritures vers la source sont arrêtées : la valeur de Latency est 0 ou proche de 0. Les informations Latency peuvent être obtenues à partir de l’écran des détails de la migration, comme indiqué ci-dessous :
• La valeur de latency diminue à 0 ou proche de 0
• La valeur de latency indique quand la cible a été synchronisée pour la dernière fois avec la source. Les écritures vers la source peuvent alors être arrêtées et le basculement peut être lancé. Si le trafic est important au niveau de la source, nous vous recommandons d’arrêter d’abord les écritures afin que Latency puisse atteindre une valeur proche de 0, puis de lancer le basculement.

L’opération de basculement applique toutes les modifications en attente de la source vers la cible, et termine la migration. Si vous déclenchez un « basculement » avec un paramètre Latency, différent de zéro, la réplication s’arrête jusqu’à ce point dans le temps. Toutes les données de la source jusqu’au point de basculement sont ensuite appliquées à la cible. Si vous rencontrez une latence de 15 minutes au point de basculement, toutes les données modifiées durant les 15 dernières minutes sont appliquées à la cible. Le temps nécessaire dépend du backlog des changements survenus au cours des 15 dernières minutes. Par conséquent, nous vous recommandons d’attendre que la latence atteigne zéro ou une valeur proche de zéro avant de déclencher le basculement.

• La migration passe à l’état Succeeded dès que le sous-état Migrating Data ou le basculement (dans la migration en ligne) s’est correctement terminé. S’il y a un problème au niveau du sous-état Migrating Data, la migration passe à l’état Failed.

Annuler la migration

Vous pouvez annuler toutes les validations ou migrations en cours. Le workflow doit être dans l’état InProgress pour être annulé. Vous ne pouvez pas annuler une validation ou une migration à l’état Réussi ou Échec.

L’annulation d’une validation arrête toute activité de validation supplémentaire et la validation passe à l’état Annulé.

L’annulation d’une migration arrête l’activité de migration supplémentaire sur votre serveur cible et passe à l’état Annulé. Elle n’annule ni ne restaure aucune modification sur votre serveur cible. Veillez à supprimer les bases de données de votre serveur cible impliqué dans une migration annulée.

Cet article explore l’utilisation d’Azure CLI pour migrer votre base de données PostgreSQL à partir d’une machine virtuelle Azure ou d’une instance PostgreSQL locale vers une instance d’Azure Database pour PostgreSQL. Azure CLI fournit une interface de ligne de commande puissante et flexible qui vous permet d’effectuer différentes tâches, notamment la migration de base de données. En suivant les étapes décrites dans cet article, vous pouvez transférer en toute transparence votre base de données vers Azure et tirer parti de sa scalabilité et de ses puissantes fonctionnalités.

Pour en savoir plus sur Azure CLI avec le service de migration, consultez Guide pratique pour configurer Azure CLI pour le service de migration.

Une fois l’interface CLI installée, ouvrez l’invite de commandes et connectez-vous à votre compte Azure à l’aide de la commande ci-dessous.

az login

Configurer la tâche de migration

Pour commencer la migration, créez un fichier JSON avec les détails de la migration. Le fichier JSON contient les informations suivantes :

• Modifiez les espaces réservés << >> ci-dessous dans les lignes JSON et stockez-les sur l’ordinateur local en tant que <<filename>>.json où l’interface CLI est appelée. Dans ce didacticiel, nous avons enregistré le fichier dans C:\migration-CLI\migration_body.json

{
"properties": {
"SourceDBServerResourceId": "<<source hostname or IP address>>:<<port>>@<<username>>",
        "SecretParameters": {
            "AdminCredentials": {
                "SourceServerPassword": "<<Source Password>>",
                "TargetServerPassword": "<<Target Password>>"
            },
			"targetServerUserName": "<<Target username>>"
        },
        "DBsToMigrate": "<<comma separated list of databases in a array like - ["ticketdb","timedb","inventorydb"]>>",
        "OverwriteDBsInTarget": "true",
        "sourceType": "OnPremises",
        "sslMode": "Prefer"
    }
}

• Exécutez la commande suivante pour vérifier si des migrations sont en cours d’exécution. Le nom de la migration est unique dans les migrations au sein du serveur flexible Azure Database pour PostgreSQL cible.

  az postgres flexible-server migration list --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --filter All
  

• Dans les étapes ci-dessus, aucune migration n’est effectuée. Nous commençons par la nouvelle migration en exécutant la commande suivante.

  az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --migration-mode online --migration-option ValidateAndMigrate --properties "C:\migration-cli\migration_body.json"
  

• Exécutez la commande suivante pour lancer l’état de la migration à l’étape précédente. Vous pouvez vérifier l’état de la migration en fournissant le nom de la migration.

  az postgres flexible-server migration show --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1
  

• L’état de la progression de la migration s’affiche dans Azure CLI.

• Vous pouvez également voir l’état du serveur flexible Azure Database pour PostgreSQL sur le Portail Azure.

• Vous pouvez annuler toutes les tentatives de migration en cours à l’aide de la commande cancel. Cette commande arrête la tentative de migration spécifique et restaure toutes les modifications sur votre serveur cible. Voici la commande CLI pour supprimer une migration :

  az postgres flexible-server migration update cancel --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1
  

Basculement

• Dans les migrations en ligne, une fois la migration des données de base terminée, la tâche de migration passe au sous-état WaitingForCutoverTrigger. Dans cet état, l’utilisateur peut déclencher le basculement via l’interface CLI à l’aide de la commande ci-dessous. Le basculement peut également être déclenché à partir du portail en sélectionnant le nom de la migration dans la grille de migration.

• Vous pouvez également lancer le basculement à partir du Portail Azure.

  az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --cutover