Tutoriel : Migration en ligne à partir d’Amazon Aurora PostgreSQL vers Azure Database pour PostgreSQL à l’aide du service de migration

Le portail Azure offre une expérience simple et intuitive basée sur un Assistant qui vous guide tout au long de la migration. En suivant les étapes décrites dans ce tutoriel, vous pouvez transférer facilement votre base de données vers Azure Database pour PostgreSQL – Serveur flexible et tirer parti de sa scalabilité et de ses puissantes fonctionnalités.

Pour migrer en utilisant le portail Azure, commencez par configurer la tâche de migration. Ensuite, connectez-vous à la source et à la cible, puis lancez la migration.

Configurer la tâche de migration

Pour configurer la tâche de migration dans le portail Azure :

1. Ouvrez votre navigateur web pour accéder au Portail Azure. Entrez vos informations d’identification pour vous connecter.

2. Accédez à votre instance d’Azure Database pour PostgreSQL – Serveur flexible.

3. Dans le menu de service, sélectionnez Migration.

   

4. Sélectionnez Créer pour effectuer une migration à partir d’Amazon Aurora vers un serveur flexible.

   La première fois que vous utilisez le service de migration, une grille vide s’affiche avec une invite pour commencer votre première migration. Si des migrations vers votre cible de serveur flexible ont déjà été créées, la grille contient des informations sur les tentatives de migration.

5. Sélectionnez Créer pour parcourir une série d’onglets permettant de configurer une migration.

   

Programme d’installation

Entrez ou sélectionnez les informations suivantes :

• Nom de la migration : entrez un identificateur unique pour chaque migration vers cette cible de serveur flexible. Vous pouvez utiliser seulement des caractères alphanumériques et des traits d’union (-) dans le nom de la migration. Le nom ne peut pas commencer par un trait d’union et il 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 : sélectionnez le type de source qui correspond à votre source PostgreSQL, par exemple un service PostgreSQL basé sur le cloud, une configuration locale ou une machine virtuelle.

• Option de migration : choisissez l’une des options suivantes pour une validation de la prémigration :

  • Validez. Vérifie la préparation de votre serveur et de votre base de données pour la migration vers la source cible.
  • Migrer. Ignore les validations et démarre la migration.
  • Valider et migrer. Effectue une validation avant de déclencher une migration. En l’absence d’échecs de validation, la migration est déclenchée.

  Une bonne pratique consiste à sélectionner l’option Valider ou Valider et migrer pour les validations de prémigration.

  Pour en savoir plus, consultez Validations de prémigration.

• Mode de migration : sélectionnez le mode de la migration. L’option par défaut est Hors connexion.

Sélectionnez Suivant : Connexion à la source.

Sélectionner le serveur d’exécution

Le serveur d’exécution de migration est une fonctionnalité spécialisée du service de migration. Le serveur d’exécution agit en tant que serveur intermédiaire pendant la migration. Il s’agit d’une instance distincte d’Azure Database pour PostgreSQL – Serveur flexible qui n’est pas le serveur cible. Le serveur d’exécution facilite la migration des bases de données depuis un environnement source accessible seulement via un réseau privé.

Pour plus d’informations, consultez Serveur d’exécution de migration.

Se connecter à la source

Sous l’onglet Connexion à la source, entrez ou sélectionnez les informations suivantes pour la source de base de données :

• Nom du serveur : entrez le nom d’hôte ou l’adresse IP de l’instance PostgreSQL source.
• Port : entrez le numéro de port du serveur source.
• Nom de connexion de l’administrateur du serveur : entrez le nom d’utilisateur du serveur PostgreSQL source.
• Mot de passe : entrez le mot de passe du serveur PostgreSQL source.
• Mode SSL : les valeurs prises en charge sont Préférer et Exiger. Quand SSL (Secure Sockets Layer) est désactivé sur le serveur PostgreSQL source, sélectionnez Préférer. Si SSL est activé sur le serveur source, sélectionnez Exiger. Les valeurs pour SSL peuvent être définies dans le fichier postgresql.conf.
• Tester la connexion : effectue un test de connectivité entre la cible et la source. Une fois la connexion établie, passez à l’étape suivante pour identifier les problèmes réseau entre la cible et la source, et pour vérifier le nom d’utilisateur et le mot de passe de la source. L’établissement d’une connexion de test prend quelques minutes.

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

Sélectionner la cible de migration

Sous l’onglet Sélectionner la cible de migration, entrez ou sélectionnez les informations suivantes pour la cible de serveur flexible, en plus de l’abonnement, du groupe de ressources et du nom du serveur :

• Nom d’utilisateur de l’administrateur : le nom d’utilisateur de l’administrateur du serveur PostgreSQL cible.
• Mot de passe : le mot de passe du serveur PostgreSQL cible.
• Nom de domaine complet/IP personnalisé (facultatif) : le champ FQDN/IP personnalisé est facultatif et peut être utilisé lorsque la cible se trouve derrière un serveur DNS personnalisé ou possède des espaces de noms DNS personnalisés, ce qui le rend accessible uniquement via des noms de domaine complets ou des adresses IP spécifiques. Par exemple, cela peut inclure des entrées telles que flexibleserver.example.com, 198.1.0.2ou un nom de domaine complet PostgreSQL tel que flexibleserver.postgres.database.azure.com, si le serveur DNS personnalisé contient la zone DNS postgres.database.azure.com ou transfère des requêtes pour cette zone à 168.63.129.16, où le nom de domaine complet est résolu dans la zone DNS publique ou privée Azure.
• Tester la connexion : effectue un test de connectivité entre la cible et la source. Une fois la connexion établie, passez à l’étape suivante pour identifier les problèmes réseau entre la cible et la source, et pour vérifier le nom d’utilisateur et le mot de passe du serveur cible. L’établissement d’une connexion de test prend quelques minutes.

Une fois le test de la connexion réussi, sélectionnez Suivant : Sélectionner une ou plusieurs bases de données pour la migration.

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

Sous l’onglet Sélectionner une base de données pour la migration, effectuez une sélection dans la liste des bases de données utilisateur à migrer depuis votre serveur PostgreSQL source.

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 informations, puis sélectionnez Démarrer la validation et la migration.

Surveiller la migration

Quelques secondes après avoir sélectionné Démarrer la validation et la migration, vous voyez apparaître une notification indiquant que la validation ou la création de la migration a réussi. Vous êtes redirigé vers le volet Migration de l’instance de serveur flexible. L’entrée de l’état est InProgress et le sous-état PerformingPreRequisiteSteps. Il faut 2 à 3 minutes pour que le flux de travail configure l’infrastructure de migration et vérifie les connexions réseau.

La grille qui affiche les migrations comporte les colonnes suivantes :

• Nom
• État
• Mode de migration
• Type de migration
• Serveur source
• Type du serveur source
• Bases de données
• Durée
• Heure de début

Les entrées sont affichées dans l’ordre décroissant des heures de début, avec l’entrée la plus récente en haut. Vous pouvez sélectionner Actualiser dans la barre de menus pour actualiser l’état d’exécution de la validation ou de la migration.

Détails de la migration

Dans la liste des migrations, sélectionnez le nom d’une migration pour voir les détails associés.

Sous l’onglet Configuration, sélectionnez l’option de migration Valider et migrer. Dans ce scénario, les validations sont effectuées 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 workflow passe au sous-état Migration des données.

Vous pouvez vérifier les détails de la validation au niveau de l’instance et au niveau de la base de données :

• Validation au niveau de l’instance :

  • Vérifiez la validation liée à la vérification de la connectivité pour la version de la source (vérification du paramètre PostgreSQL version >= 9.5 du serveur) si les extensions sont activées dans les paramètres de serveur de l’instance d’Azure Database pour PostgreSQL – Serveur flexible.

• Validation au niveau de la base de données :

  • Vérifiez la validation des bases de données individuelles liées aux extensions et à la prise en charge des classements dans Azure Database pour PostgreSQL – Serveur flexible.

Vous pouvez voir l’état actuel de la validation et de la migration dans le volet de détails de la migration.

Les tableaux suivants décrivent certains états et sous-états possibles de la migration.

États de migration

Sous-états de la migration

Sous-états de validation

Lancer un basculement

Si Migrer et Valider et migrer apparaissent tous les deux, l’exécution de la migration en ligne nécessite l’étape supplémentaire de lancement d’un basculement. Après avoir effectué la copie et 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 dans la source sont arrêtées.
• La valeur latency diminue à 0 ou proche de 0.

Vous pouvez obtenir la valeur latency dans le volet de détails de la migration :

La valeur de latency indique quand la cible a été synchronisée pour la dernière fois avec la source. À ce stade, les écritures vers la source peuvent être arrêtées et le basculement peut être lancé. S’il existe un trafic important sur le serveur source, nous vous recommandons d’arrêter d’abord les écritures afin que latency puisse atteindre près de 0. Lancez ensuite un basculement.

L’opération de basculement applique tous les changements en attente de la source vers la cible et effectue la migration. Si vous déclenchez un basculement avec une valeur de latency différente de zéro, la réplication s’arrête jusqu’à ce point dans le temps. Toutes les données se trouvent sur la source jusqu’à ce que le point de basculement soit appliqué à la cible. Par exemple, si la latence est de 15 minutes au point de basculement, toutes les données modifiées au cours des 15 dernières minutes sont appliquées à la cible. Le temps nécessaire au basculement dépend du backlog des modifications qui se sont produites pendant ces 15 minutes. Par conséquent, nous recommandons d’atteindre une latence de zéro ou près de zéro avant de déclencher le basculement.

La migration passe à l’état Réussi dès que le sous-état Migration des données ou que le basculement (pour une migration en ligne) se termine correctement. En cas de problème au sous-état Migration des données, la migration passe à un état Échec.

Cet article explique comment utiliser Azure CLI pour migrer votre base de données PostgreSQL d’Amazon Aurora vers Azure Database pour PostgreSQL. Azure CLI est 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.

Pour plus d’informations, consultez Configurer Azure CLI pour le service de migration.

Une fois Azure CLI installé, en utilisant la ligne de commande, connectez-vous à votre compte Azure avec la commande suivante :

az login

Configurer la tâche de migration

1. Pour commencer la migration, créez un fichier JSON avec les détails de la migration. Enregistrez le fichier JSON sur votre ordinateur local en tant que <nom de fichier>.json. Par exemple, vous pouvez enregistrer le fichier sous C:\migration-CLI\migration_body.json.

   Copiez le JSON suivant et collez-le dans le fichier JSON. Remplacez <placeholders> par les informations pertinentes pour votre scénario.

   {
   "properties": {
   "SourceDBServerResourceId": "<source host name or IP address>:<port>@<username>",
           "SecretParameters": {
               "AdminCredentials": {
                   "SourceServerPassword": "<source password>",
                   "TargetServerPassword": "<target password>"
               },
               "targetServerUserName": "<target username>"
           },
           "DBsToMigrate": "<a comma-separated list of databases in an array, similar to the example "ticketdb","timedb","inventorydb">",
           "OverwriteDBsInTarget": "true",
           "sourceType": "AWS_AURORA",
           "sslMode": "Require"
       }
   }
   

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

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

3. Dans les étapes précédentes, aucune migration n’est effectuée. Démarrez 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"
   

4. 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 migration s’affiche dans Azure CLI. Vous pouvez également voir l’état de l’instance d’Azure Database pour PostgreSQL – Serveur flexible sur le Portail Azure.

Annuler ou supprimer une migration

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 annule 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, vous pouvez déclencher le basculement à l’aide de la commande suivante dans Azure CLI :

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

Vous pouvez également déclencher le basculement dans le portail en sélectionnant le nom de la migration dans la grille de migration.