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

Cet article explique comment migrer votre base de données PostgreSQL d’Amazon Aurora vers Azure Database pour PostgreSQL en ligne.

Le service de migration dans Azure Database pour PostgreSQL est un service complètement managé qui est intégré au Portail Azure et à Azure CLI. Il est conçu pour simplifier votre parcours de migration vers Azure Database pour PostgreSQL.

Dans ce tutoriel, vous allez :

• Répondre aux prérequis
• Lancer la migration
• Surveiller la migration
• Lancer un basculement
• Vérifier la migration

Prérequis

Avant de commencer une migration à l’aide du service de migration dans Azure Database pour PostgreSQL, il est important de remplir les conditions préalables suivantes. Ces prérequis sont spécifiquement conçus pour les scénarios de migration en ligne.

• Vérifier la version source
• Installer test_decoding pour la configuration de la source
• Définir la configuration cible
• Activer la capture des changements de données en tant que source
• Définir la configuration réseau
• Activer les extensions
• Vérifier les paramètres de serveur
• Vérifier les utilisateurs et les rôles

Vérifier la version source

La version du serveur PostgreSQL source doit être 9.5 ou une version ultérieure. Si la version PostgreSQL source est inférieure à 9.5, mettez-la à niveau vers la version 9.5 ou ultérieure avant de commencer la migration.

Installer test_decoding pour la configuration de la source

• Le plug-in test_decoding reçoit la journalisation write-ahead (WAL) par le biais du mécanisme de décodage logique. Le plug-in décode le journal WAL en représentations textuelles des opérations effectuées.
• Dans Amazon RDS pour PostgreSQL, le plug-in test_decoding est préinstallé et prêt pour la réplication logique. Vous pouvez facilement configurer des emplacements de réplication logique et diffuser en continu les modifications du journal WAL telles que la capture des changements de données (CDC) ou la réplication vers des systèmes externes.

Pour plus d’informations sur le plug-in test_decoding, consultez la documentation PostgreSQL.

Définir la configuration cible

Avant de commencer la migration, vous devez créer une instance d’Azure Database pour PostgreSQL dans Azure. La référence SKU approvisionnée pour Azure Database pour PostgreSQL – Serveur flexible doit correspondre à la source.

Pour plus d’informations, consultez Créer une instance d’Azure Database pour PostgreSQL.

Activer la capture des changements de données en tant que source

• Le plug-in de décodage logique test_decoding capture les enregistrements modifiés de la source.

• Pour autoriser l’utilisateur de migration à accéder aux autorisations de réplication, exécutez la commande suivante :

  GRANT rds_replication TO <username>;
  

• Dans l’instance PostgreSQL source, modifiez les paramètres suivants dans le groupe de paramètres de clusters de base de données en créant un nouveau groupe de paramètres :

  • Affectez la valeur rds.logical_replication à 1.
  • Définissez max_replication_slots sur une valeur supérieure à 1. La valeur doit être supérieure au nombre de bases de données sélectionnées pour la migration.
  • Définissez max_wal_senders sur une valeur supérieure à 1. La valeur doit être au moins identique à la valeur de max_replication_slots, plus le nombre d’expéditeurs déjà utilisés dans votre instance.
  • Le paramètre wal_sender_timeout met fin aux connexions de réplication inactives depuis plus que le nombre spécifié de millisecondes. La valeur par défaut pour une instance d’Amazon Aurora PostgreSQL est 30000 milliseconds (30 seconds). Définissez la valeur sur 0 (zero) pour désactiver le mécanisme d’expiration, ce qui constitue un paramètre valide pour la migration.

• Dans le serveur flexible cible, pour éviter que la migration en ligne ne manque d’espace de stockage pour les journaux, assurez-vous que vous disposez de suffisamment de stockage dans votre espace de table en utilisant un disque managé approvisionné. Désactivez le paramètre de serveur azure.enable_temp_tablespaces_on_local_ssd pendant la durée de la migration. Restaurez le paramètre à l’état d’origine après la migration.

Définir la configuration réseau

La configuration du réseau est cruciale pour que le service de migration fonctionne correctement. Vérifiez que le serveur PostgreSQL source peut communiquer avec le serveur cible dans Azure Database pour PostgreSQL.

Pour plus d’informations sur la configuration réseau, consultez Scénarios réseau pour le service de migration.

Activer les extensions

Pour garantir une migration réussie à l’aide du service de migration dans Azure Database pour PostgreSQL, vous allez peut-être devoir vérifier les extensions de votre instance PostgreSQL source. Les extensions fournissent des fonctionnalités qui peuvent être requises pour votre application. Assurez-vous de vérifier les extensions sur l’instance PostgreSQL source avant de lancer le processus de migration.

Sur l’instance cible d’Azure Database pour PostgreSQL – Serveur flexible, activez les extensions prises en charge et identifiées dans l’instance PostgreSQL source.

Pour plus d’informations, consultez Extensions dans Azure Database pour PostgreSQL.

Remarque

Un redémarrage est nécessaire lorsqu’une modification est apportée au paramètre shared_preload_libraries.

Vérifier les paramètres de serveur

Les paramètres de serveur ne sont pas automatiquement migrés vers l’environnement cible et doivent être configurés manuellement.

• Faites correspondre les valeurs des paramètres de serveur de la base de données PostgreSQL source à l’instance d’Azure Database pour PostgreSQL. Sur le Portail Azure, accédez à Paramètres du serveur et mettez à jour manuellement les valeurs.

• Enregistrez les modifications apportées aux paramètres et redémarrez l’instance d’Azure Database pour PostgreSQL pour appliquer la nouvelle configuration si nécessaire.

Vérifier les utilisateurs et les rôles

Lors de la migration vers Azure Database pour PostgreSQL, il est essentiel de traiter séparément la migration des utilisateurs et des rôles, car une intervention manuelle est nécessaire.

• Migration manuelle des utilisateurs et des rôles : les utilisateurs et leurs rôles associés doivent être migrés manuellement vers l’instance d’Azure Database pour PostgreSQL. Pour faciliter ce processus, vous pouvez utiliser l’utilitaire pg_dumpall avec l’indicateur --globals-only pour exporter des objets globaux tels que des rôles et des comptes d’utilisateur.

  Exécutez la commande suivante. Remplacez <username> par le nom d’utilisateur réel, puis remplacez <filename> par le nom que vous souhaitez utiliser pour le fichier de sortie.

  pg_dumpall --globals-only -U <username> -f <filename>.sql
  

• Restriction sur les rôles de superutilisateur : Azure Database pour PostgreSQL ne prend pas en charge les rôles de superutilisateur. Les autorisations de superutilisateur doivent être supprimées avant la migration. Veillez à ajuster les autorisations et les rôles en conséquence.

En suivant ces étapes, vous pouvez vous assurer que les comptes d’utilisateur et les rôles sont correctement migrés vers Azure Database pour PostgreSQL sans rencontrer de problèmes liés aux restrictions de superutilisateur.

Désactiver les réplicas de haute disponibilité (fiabilité) et de lecture dans la cible

Il est essentiel de désactiver la haute disponibilité (fiabilité) et les réplicas de lecture dans l’environnement cible avant de lancer la migration. Ces fonctionnalités doivent uniquement être activées une fois la migration terminée.

Lancer la migration

Vous pouvez migrer à l’aide du Portail Azure ou d’Azure CLI.

Azure portal

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 en toute transparence 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 à l’aide du 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 sur 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 ne pouvez utiliser que 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 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 la 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 de runtime

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

Pour plus d’informations, consultez Serveur de runtime 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 : indiquez 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éré et Obligatoire. Lorsque SSL (Secure Sockets Layer) est désactivé sur le serveur PostgreSQL source, sélectionnez Préféré. Si SSL est activé sur le serveur source, sélectionnez Obligatoire. Les valeurs 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 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 la connexion test établie, 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 administrateur : le nom d’utilisateur administrateur du serveur PostgreSQL cible.

• Mot de passe : le mot de passe du serveur PostgreSQL cible.

• 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 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 la connexion test établie, sélectionnez Suivant : Sélectionner les 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 à partir de 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

Une notification s’affiche quelques secondes après avoir sélectionné Démarrer la validation et la migration pour indiquer 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 d’é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 de l’heure 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 afficher les détails associés.

Dans 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 flux de travail passe au sous-état Validation en cours.

• Si la validation présente des erreurs, la migration passe à l’état Échec.

• Si la validation est terminée sans erreur, la migration démarre et le flux de travail passe au sous-état Migration des données.

Vous pouvez vérifier les détails de 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é, 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 du 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

State	Description
InProgress	L’infrastructure de migration est en cours de configuration, ou la migration des données est en cours.
Annulé	La migration est annulée ou supprimée.
Échec	La migration a échoué.
Échec de la validation	La validation a échoué.
Réussi	La migration a réussi et est terminée.
WaitingForUserAction	Applicable uniquement pour les migrations en ligne. En attente de basculement par un utilisateur.

Sous-états de la migration

Sous-état	Description
PerformingPreRequisiteSteps	L’infrastructure est en cours de configuration pour la migration des données.
Validation en cours	La validation est en cours.
MigratingData	La migration des données est en cours.
CompletingMigration	La migration est en phase finale.
Terminé	La migration est terminée.
Échec	La migration a échoué.

Sous-états de validation

Sous-état	Description
Échec	Échec de la validation.
Réussi	La validation a réussi.
Avertissement	La validation affiche un avertissement.

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.

Azure CLI

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 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.

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

Une fois Azure CLI installé, à la ligne de commande, connectez-vous à votre compte Azure à l’aide de 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 des informations pertinentes de 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 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, 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.

Vérifier la migration

Une fois la migration de base de données terminée, validez manuellement les données entre la source et la cible. Vérifiez que tous les objets de la base de données cible sont correctement créés.

Après la migration, vous pouvez effectuer ces tâches :

• Vérifiez les données sur votre serveur flexible et vérifiez qu’il s’agit d’une copie exacte de l’instance source.
• Après vérification, activez l’option de haute disponibilité sur votre serveur flexible si nécessaire.
• Changez la référence SKU (version) du serveur flexible en fonction des besoins de votre application. Cette modification nécessite un redémarrage du serveur de base de données.
• Si vous modifiez les valeurs par défaut de certains paramètres de serveur sur l’instance source, copiez les valeurs de ces paramètres de serveur dans le serveur flexible.
• Copiez d’autres paramètres de serveur, tels que les étiquettes, les alertes et les règles de pare-feu (le cas échéant), de l’instance source vers le serveur flexible.
• Apportez des modifications à votre application pour lui faire pointer les chaînes de connexion vers un serveur flexible.
• Surveillez de près le niveau de performance des bases de données pour déterminer s’il est nécessaire de l’ajuster.

Contenu connexe

• Migrer hors ligne à partir d’Amazon Aurora PostgreSQL
• Service de migration
• Effectuer une migration à partir de machines virtuelles locales et Azure
• Problèmes connus et limitations