Tutoriel : Migration hors ligne à partir d’Amazon RDS pour 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 RDS pour PostgreSQL vers Azure Database pour PostgreSQL hors ligne.

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

  • Prérequis
  • Effectuer la migration
  • Surveiller la migration
  • Vérifier la migration une fois terminée

Prérequis

Pour terminer la migration, vous devez disposer des prérequis suivants :

Avant de commencer la migration avec le service de migration Azure Database pour PostgreSQL, il est important de vérifier que les prérequis suivants, spécialement conçus pour les scénarios de migration hors connexion, sont satisfaits.

Vérifier la version source

La version du serveur PostgreSQL source doit être 9.5 ou une version ultérieure.

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

Définir la configuration cible

Avant de commencer la migration, vous devez configurer une instance d’Azure Database pour PostgreSQL dans Azure.

La référence SKU choisie pour Azure Database pour PostgreSQL doit correspondre aux spécifications de la base de données source afin de garantir la compatibilité et des performances adéquates.

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 Azure Database pour PostgreSQL cible. Les configurations réseau suivantes sont essentielles pour une migration réussie.

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

Activer les extensions

Pour garantir la réussite de la migration à l’aide du service de migration dans Azure Database pour PostgreSQL, il peut être nécessaire de vérifier les extensions de votre instance PostgreSQL source. Les extensions fournissent des fonctionnalités qui peuvent être requises pour votre application. Veillez à 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

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

  • Faites correspondre les valeurs des paramètres du serveur de la base de données PostgreSQL source à Azure Database pour PostgreSQL en accédant à la section « Paramètres du serveur » dans le Portail Azure et en mettant à jour manuellement les valeurs en conséquence.

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

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 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, en remplaçant <<username>> par le nom d’utilisateur réel et <<filename>> par le nom de fichier de sortie souhaité :

    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. Par conséquent, les privilèges de superutilisateur accordés aux utilisateurs doivent être supprimés avant la migration. Veillez à ajuster les autorisations et les rôles en conséquence.

En procédant ainsi, 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 associés aux rôles de superutilisateur.

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

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

  • En procédant ainsi, vous pouvez garantir un processus de migration fluide sans les variables ajoutées introduites par les réplicas de haute disponibilité et de lecture. Une fois la migration terminée et la base de données stable, vous pouvez activer ces fonctionnalités pour améliorer la disponibilité et la scalabilité de votre environnement de base de données dans Azure.

Effectuer la migration

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

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 un serveur flexible Azure Database pour PostgreSQL et tirer parti de sa scalabilité et de ses puissantes fonctionnalités.

Pour migrer avec le Portail Azure, vous configurez d’abord la tâche de migration, vous connectez à la source et à la cible, puis effectuez la migration.

Configurer la tâche de migration

Le service de migration inclut une expérience simple basée sur un Assistant sur le Portail Azure.

  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 serveur flexible Azure Database pour PostgreSQL.

  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.

    Capture d’écran de la sélection de la migration dans le portail Azure.

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

    Remarque

    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 le serveur flexible cible ont déjà été créées, la grille contient des informations sur les tentatives de migration.

  5. Sélectionnez le bouton Créer pour parcourir une série d’onglets de type Assistant pour effectuer une migration.

    Capture d’écran de la page de création de la migration.

Programme d’installation

L’utilisateur doit fournir plusieurs informations liées à la migration, comme le nom de la migration, le type de serveur source, l’option et le mode.

  • 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 Amazon RDS pour PostgreSQL.

  • 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. En l’absence d’échecs de validation, la migration est déclenchée.

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 les validations de prémigration, consultez la section Prémigration.

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

Capture d’écran de la page Configurer la migration pour commencer.

Sélectionner un serveur d’exécution

Le serveur d’exécution de migration est une fonctionnalité spécialisée intégrée au service de migration, 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 qui est utilisée 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, consultez Serveur d’exécution de migration.

Capture d’écran de 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 Installation, 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 ; ils doivent 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 le test de connexion réussi, sélectionnez le bouton Suivant : Sélectionner une cible de migration.

Capture d’écran de la page de connexion à la source.

Sélectionner la cible de migration

L’onglet Sélectionner une cible de migration affiche les métadonnées du serveur flexible cible comme 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
  • FQDN/IP personnalisé (facultatif) : le champ FQDN/IP personnalisé est facultatif. Il peut être utilisé quand la cible se trouve derrière un serveur DNS personnalisé, ou dispose d’espaces de noms DNS personnalisés, ce qui le rend accessible uniquement via des FQDN ou des adresses IP spécifiques. Par exemple, cela peut inclure des entrées telles que flexibleserver.example.com, 198.1.0.2 ou un FQDN PostgreSQL tel que flexibleserver.postgres.database.azure.com, si le serveur DNS personnalisé contient la zone DNS postgres.database.azure.com, ou transfère les requêtes de cette zone vers 168.63.129.16, où le FQDN est résolu dans la zone DNS publique ou privée Azure.
  • 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. Autrement, nous devons 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 cible. 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 le bouton Suivant : Sélectionner la ou les bases de données à migrer.

Capture d’écran de la page de connexion à la migration cible.

Sélectionner une base de données pour la migration

Sous l’onglet Sélectionner une base de données à migrer, vous pouvez choisir une liste de 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é

Capture d’écran de la page de migration fetchDB.

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 et sélectionnez le bouton Démarrer la validation et la migration.

Capture d’écran de la page de résumé de la migration.

Surveiller la migration

Une notification s’affiche quelques secondes après avoir sélectionné le bouton Démarrer la validation et la migration pour indiquer que la validation ou la migration a été créée. Vous êtes redirigé vers l’instance de la page Migration de serveur flexible. L’entrée se trouve dans l’état InProgress et le sous-état PerformingPreRequisiteSteps. Il faut 2 à 3 minutes que le flux de travail configure l’infrastructure de migration et vérifie les connexions réseau.

Capture d’écran de la page de surveillance de la migration.

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 l’exécution de la validation ou de la migration.

Détails de la migration

Sélectionnez le nom de la migration dans la grille pour afficher les informations associées.

Dans l’onglet Installation, nous avons défini l’option de migration sur Validation et Migration. Dans ce scénario, les validations sont effectuées en premier avant le début de la migration. Une fois que le sous-état PerformingPreRequisiteSteps est terminé, le flux de travail passe au sous-état de 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.

Les détails de validation sont disponibles au niveau de l’instance et de la base de données.

  • Validation au niveau de l’instance

    • Contient la validation liée à la vérification de la connectivité, la version de la source, autrement dit, PostgreSQL version >= 9.5, la vérification des paramètres du serveur, autrement dit, si les extensions sont activées dans les paramètres serveur d’Azure Database pour PostgreSQL – Serveur flexible.
  • Validation au niveau de la base de données

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

Vous pouvez voir l’état de la validation et de la migration dans la page Détails de la migration.

Capture d’écran des détails montrant la validation et la migration.

Les états de migration possibles incluent :

É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 la migration en ligne. Attente d’une action de l’utilisateur pour effectuer le basculement.

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 La validation a échoué.
Réussi La validation a réussi.
Avertissement La validation présente un avertissement.

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 qui se trouve dans l’état Réussi ou Échec.

  • L’annulation d’une migration arrête l’activité de migration supplémentaire sur votre serveur cible et passe à l’état Annulé. L’action d’annulation restaure toutes les modifications apportées par le service de migration sur votre serveur cible.

Vérifier la migration une fois terminée

Une fois les bases de données terminées, vous devez valider manuellement les données entre la source et la cible et vérifier que tous les objets de la base de données cible sont bien créés.

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

  • 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, et si cela est nécessaire, activez l’option haute disponibilité sur votre serveur flexible.
  • Changez la référence SKU du serveur flexible en fonction des besoins d’applications. 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.