Tutoriel : Migration à partir d’AWS RDS PostgreSQL vers Azure Database pour PostgreSQL à l’aide du service de migration

S’APPLIQUE À : Azure Database pour PostgreSQL – Serveur flexible

Ce didacticiel vous guide dans la migration d’une instance PostgreSQL à partir d’AWS RDS vers Azure Database pour un serveur flexible PostgreSQL avec le Portail Azure et Azure CLI.

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

• Configurez votre instance de serveur flexible Azure Database pour PostgreSQL
• Configurer la tâche de migration
• Surveiller la migration
• Annuler la migration
• Après la migration

Prérequis (hors connexion)

Avant de commencer votre migration avec le service de migration dans Azure Database pour PostgreSQL, vous devez satisfaire les conditions préalables suivantes, qui s’appliquent aux scénarios de migration hors connexion.

Vérifier la version source

La version de PostgreSQL source doit être >= 9.5. Si la version de PostgreSQL source est inférieure à 9.5, mettez à niveau la version de PostgreSQL source vers la version 9.5 ou ultérieure avant la migration.

Configuration cible :

• Azure Database pour PostgreSQL doit être configuré dans Azure avant la migration.

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

• Pour obtenir des instructions détaillées sur la création d’une Azure Database pour PostgreSQL, reportez-vous au lien suivant : Démarrage rapide : Créer un serveur.

Configuration du réseau

Une configuration réseau appropriée est essentielle pour garantir une connectivité réussie entre la source et la cible pendant la migration. Voici un guide pour vous aider à établir la connexion réseau dans différents scénarios :

Configuration réseau requise pour la migration :

• Tunneling ExpressRoute/VPN IPsec/VPN : lors de la connexion de votre source locale/AWS à Azure, vous devrez peut-être configurer un tunneling ExpressRoute, VPN IPsec ou VPN pour faciliter le transfert de données sécurisé.

• Appairage de réseaux virtuels : établissez un appairage de réseaux virtuels entre les deux réseaux virtuels distincts pour activer la connectivité réseau directe, condition préalable à la migration entre la machine virtuelle Azure et Azure Database pour PostgreSQL.

Scénarios de connectivité :

Le tableau suivant peut vous aider à configurer le réseau entre la source et la cible.

Source	Cible	Conseils de connectivité
Public	Public	Aucune autre action n’est requise si la source est mise en liste verte dans les règles de pare-feu de la cible.
Privé	Public	Cette configuration n’est pas prise en charge ; utilisez pg_dump/pg_restore pour le transfert de données.
Public	Privée	Aucune autre action n’est requise si la source est mise en liste verte dans les règles de pare-feu de la cible.
Privée	Privée	Établissez un tunneling ExpressRoute, VPN IPsec ou VPN, ou un appairage de réseaux virtuels entre la source et la cible.
Privée	Point de terminaison privé	Cette configuration n’est pas prise en charge ; contactez le support Microsoft.

Autres considérations relatives à la mise en réseau :

• Configuration pg_hba.conf : pour faciliter la connectivité entre les instances PostgreSQL source et cible, il est essentiel de vérifier et de modifier potentiellement le fichier pg_hba.conf. Ce fichier inclut l’authentification du client et doit être configuré pour permettre à la cible PostgreSQL de se connecter à la source. Généralement, l’instance source PostgreSQL doit être redémarrée pour que les modifications apportées au fichier pg_hba.conf prennent effet.

Remarque

Le fichier pg_hba.conf se trouve dans le répertoire de données de l’installation PostgreSQL. Ce fichier doit être vérifié et configuré si la base de données source est un serveur PostgreSQL local ou un serveur PostgreSQL hébergé sur une machine virtuelle Azure. Pour les instances PostgreSQL sur AWS RDS ou des services gérés similaires, le fichier pg_hba.conf n’est pas directement accessible ou applicable. Au lieu de cela, l’accès est contrôlé grâce aux configurations d’accès réseau et de sécurité fournies par le service.

Pour plus d’informations sur la configuration réseau, consultez le Guide réseau pour le service de migration dans Azure Database pour PostgreSQL – Serveur flexible.

Extensions

Les extensions sont des fonctionnalités supplémentaires qui peuvent être ajoutées à PostgreSQL pour en améliorer les performances. Les extensions sont prises en charge dans Azure Database pour PostgreSQL, mais doivent être activées manuellement. Pour activer les extensions, procédez comme suit :

• Utilisez la commande select dans la source pour lister toutes les extensions utilisées : select extname,extversion from pg_extension;.

• Recherchez le paramètre de serveur azure.extensions dans la page des paramètres du serveur de votre Azure Database pour PostgreSQL. Activez les extensions trouvées dans la source dans PostgreSQL.

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

  

• Vérifiez si la liste contient l’une des extensions suivantes :

  • PG_CRON
  • PG_HINT_PLAN
  • PG_PARTMAN_BGW
  • PG_PREWARM
  • PG_STAT_STATEMENTS
  • PG_AUDIT
  • PGLOGICAL
  • WAL2JSON

Si tel est le cas, accédez à la page paramètres du serveur et recherchez le paramètre shared_preload_libraries. Ce paramètre indique l’ensemble des bibliothèques d’extensions qui sont préchargées au redémarrage du serveur.

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

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.

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.

Portail

Vous pouvez effectuer une migration avec le Portail Azure.

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.

   

4. Sélectionnez le bouton Créer pour effectuer une migration à partir d’AWS RDS 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.

   

Programme d’installation

L’onglet de configuration apparaît en premier.

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 AWS 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. La migration est déclenchée en l’absence 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 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.

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 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 le bouton Suivant : Sélectionner une cible de migration.

Connecter à la cible

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

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

Sélectionner des bases 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 le bouton 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 et sélectionnez le bouton Démarrer la validation et 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 automatiquement redirigé vers la page Migration du 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.

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 ou ultérieure, 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.

Les états de migration possibles incluent :

• InProgress : l’infrastructure de migration est en cours de configuration ou la migration des données est en cours.
• Opération annulée : la migration est annulée ou supprimée.
• Failed : 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.

Les sous-états de migration possibles incluent :

• 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.
• Completed : la migration est terminée.
• Failed : la migration a échoué.

Les sous-états de validation possibles sont les suivants :

• Failed : la validation a échoué.
• Succeeded : la validation réussit.
• Warning : la validation est en Avertissement. Les avertissements sont des messages informatifs à ne pas oublier lorsque vous planifiez la migration.

Annulation de la migration à partir du portail

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 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é. L’action d’annulation va restaurer toutes les modifications apportées par le service de migration sur votre serveur cible.

INTERFACE DE LIGNE DE COMMANDE

Vous pouvez effectuer une migration à l’aide d’Azure CLI.

Pour commencer la migration à l’aide d’Azure CLI, vous devez installer l’interface de ligne de commande Azure sur votre ordinateur local.

Configurer Azure CLI pour le service de migration dans Azure Database pour PostgreSQL – Serveur flexible

• Installez Azure CLI en fonction du système d’exploitation pour exécuter les commandes CLI.
• Azure CLI peut être installé à partir de la section Comment installer Azure CLI.
• Si Azure CLI est déjà installé, vérifiez la version en émettant la commande az version. Pour que vous puissiez utiliser le service de migration, la version doit être 2.56.0 ou ultérieure.
• Une fois installé, exécutez la commande az sign in. Le navigateur s’ouvre alors et charge une page de connexion Azure pour s’authentifier. Transmettez vos informations d’identification Azure pour réussir l’authentification. Pour d’autres méthodes de connexion à Azure CLI, consultez ce lien.

Configurer les commandes CLI pour le service de migration

Toutes les commandes d’interface de ligne de commande commencent par az postgres flexible-server migration. Des instructions d’aide sont également fournies pour vous aider à comprendre les différentes options et à définir la syntaxe correcte pour les commandes CLI.

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

Exemple avec l’invite de commandes Windows : az login.

Commandes à utiliser avec le service de migration

Le service de migration fournit les commandes suivantes pour vous aider à migrer vos bases de données PostgreSQL vers Azure Database pour PostgreSQL – Serveur flexible.

Commande help

La commande az postgres flexible-server migration –-help fournit le nom et les verbes correspondants.

Commande create

La commande create permet d’effectuer une migration à partir d’un serveur source vers un serveur cible.

La commande help permet aux utilisateurs de comprendre les différents arguments utilisés pour créer et lancer la migration az postgres flexible-server migration create --help.

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --migration-option ValidateAndMigrate --properties "C:\Users\Administrator\Documents\migrationBody.JSON" --migration-mode offline

Flux de sous-états différents lorsque la commande create est déclenchée.

• La migration passe à l’état InProgress et au sous-état PerformingPreRequisiteSteps.

• Lorsque le sous-état PerformingPreRequisiteSteps est terminé, la migration passe au sous-état Migration des données où le clonage/la copie des bases de données a lieu.

• Chaque base de données migrée a sa section contenant toutes les informations de migration telles que le nombre de tables, les insertions incrémentielles, les suppressions et les octets en attente.

• Le temps nécessaire pour que le sous-état Migration des données prenne fin dépend de la taille des bases de données migrées.

• La migration passe à l’état Succeeded dès que le sous-état Migration des données se termine correctement. En cas de problème au cours du sous-état Migration des données, la migration passe à un état Failed.

Comprendre les détails de chaque paramètre utilisé dans la commande create

Nom du paramètre	Description
subscription	ID d’abonnement du serveur flexible PostgreSQL
resource-group	Groupe de ressources du serveur flexible PostgreSQL
name	Nom du serveur flexible PostgreSQL
migration-name	Identificateur unique aux migrations tentées vers le 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 - et deux migrations vers un serveur flexible ne peuvent pas avoir le même nom.
migration-mode	Il s'agit d'un paramètre facultatif. Valeur par défaut : hors connexion. La migration hors connexion implique la copie de vos bases de données sources à un moment donné sur votre serveur cible.
migration-option	Vous permet d’effectuer des validations avant de déclencher une migration. La valeur par défaut est ValidateAndMigrate. Les valeurs autorisées sont : Migrate, Validate, ValidateAndMigrate.
properties	Chemin d’accès absolu à un fichier JSON qui contient les informations sur le serveur source

Vous devez fournir un fichier JSON avec le chemin d’accès absolu en tant que paramètre lors du lancement de la migration.

Le fichier JSON contient les informations suivantes :

Nom de la propriété	Description
sourceDbServerResourceId	Informations du serveur source au format local, machines virtuelles Azure, AWS : <<hostname or IP address>>:<<port>>@<<username>>
AdminCredentials	Ce paramètre répertorie les mots de passe des utilisateurs administrateurs pour le serveur source et le serveur flexible PostgreSQL cible. Ces mots de passe permettent d’effectuer une authentification auprès des serveurs source et cible.
targetServerUserName	La valeur par défaut correspond à l’utilisateur administrateur créé lors de la création d’un serveur flexible, et le mot de passe fourni est utilisé pour l’authentification par rapport à cet utilisateur. Si vous n’utilisez pas l’utilisateur par défaut, ce paramètre est l’utilisateur ou le rôle sur le serveur cible de la migration. Cet utilisateur doit être membre des rôles azure_pg_admin, pg_read_all_settings, pg_read_all_stats et pg_stat_scan_tables et doit avoir les attributs Créer un rôle, Créer une base de données.
dbsToMigrate	Spécifiez la liste des bases de données que vous souhaitez migrer vers le serveur flexible. Vous pouvez inclure un maximum de 8 noms de base de données à la fois. Fournir la liste des bases de données au format tableau.
OverwriteDBsInTarget	Lorsque la valeur est « true » (valeur par défaut), si le serveur cible possède une base de données existante portant le même nom que celle que vous essayez de migrer, l’outil de migration remplace automatiquement la base de données.
MigrationMode	Mode de la migration. La valeur prise en charge est « Hors connexion ».
sourceType	Paramètre obligatoire. Les valeurs peuvent être : OnPremises, AWS, AzureVM, PostgreSQLSingleServer
sslMode	Modes SSL pour la migration. Le mode SSL pour PostgreSQLSingleServer est VerifyFull et Prefer/Require pour d’autres types de source.

Commande list.

La commande list répertorie toutes les tentatives de migration effectuées vers une cible Azure Database pour PostgreSQL.

az postgres flexible-server migration list [--subscription] [--resource-group][--name] [--filter]

Nom du paramètre	Description
subscription	ID d’abonnement du serveur flexible PostgreSQL cible
resource-group	Groupe de ressources du serveur flexible PostgreSQL cible
name	Nom du serveur flexible PostgreSQL cible
filter	Pour filtrer les migrations, deux valeurs sont prises en charge : Active et All

Commande show

La commande show permet de surveiller les migrations en cours et fournit l’état et le sous-état actuels de la migration. Ces détails incluent des informations sur l’état et le sous-état actuels de la migration.

az postgres flexible-server migration show [--subscription][--resource-group][--name][--migration-name]

Nom du paramètre	Description
subscription	ID d’abonnement du serveur flexible PostgreSQL cible
resource-group	Groupe de ressources du serveur flexible PostgreSQL cible
name	Nom du serveur flexible PostgreSQL cible
migration-name	Identificateur unique aux migrations tentées vers le 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 - et deux migrations vers un serveur flexible ne peuvent pas avoir le même nom.

Différents états pris en charge dans la commande show

État de la migration	Description
InProgress	L’infrastructure de migration est configurée, ou la migration de données réelle est en cours.
Canceled	La migration est annulée ou supprimée.
Failed	La migration a échoué.
Succeeded	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
ValidationFailed	La validation au niveau de la base de données ou du serveur a échoué.

Différents sous-états pris en charge dans la commande show pour la migration

Sous-état de la migration	Description
PerformingPreRequisiteSteps	L’infrastructure est configurée et préparée pour la migration des données.
MigratingData	La migration des données est en cours.
Completed	La migration est terminée.
Failed	La migration a échoué.
Validation in Progress	La validation est en cours.
CompletingMigration	La migration est en phase finale.

Les détails de validation sont 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 ou ultérieure, 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 aux extensions, la prise en charge des classements dans Azure Database pour PostgreSQL – Serveur flexible.

Différents sous-états pris en charge dans la commande show pour la validation.

Sous-état de la validation	Description
Failed	La validation a échoué.
Succeeded	La validation est réussie.
Warning	La validation est en Avertissement. Les avertissements sont des messages informatifs que vous devez garder à l’esprit lorsque vous planifiez la migration.

Annuler la 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 particulière, mais elle ne supprime ni ne restaure aucune modification sur votre serveur cible. Voici la commande CLI pour supprimer une migration :

az postgres flexible-server migration update cancel [--subscription][--resource-group][--name][--migration-name]

Par exemple :

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

Pour plus d’informations sur cette commande, utilisez le paramètre help :

az postgres flexible-server migration update cancel -- help

Se connecter à la source

• Pour ce didacticiel, nous allons effectuer la migration de « ticketdb », « inventorydb » et « timedb » vers un serveur flexible Azure Database pour PostgreSQL.

Effectuer une migration à l’aide de la CLI

• Ouvrez l’invite de commandes et connectez-vous à Azure à l’aide de la commande az login.

  

• 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 like - "ticketdb","timedb","inventorydb">>"
        ],
        "OverwriteDBsInTarget": "true",
        "MigrationMode": "Offline",
        "sourceType": "AWS",
        "sslMode": "Require"
    }
}

• 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 <<subscription ID>> --resource-group <<resource group name>> --name <<Name of the Flexible  Server>> --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 <<subscription ID>> --resource-group <<resource group name>> --name <<Name of the Flexible Server>> --migration-name <<Unique Migration Name>> --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 <<subscription ID>> --resource-group <<resource group name>> --name <<Name of the Flexible Server>> --migration-name <<Migration ID>>
  

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

  

• Vous pouvez également voir l’état du portail du serveur flexible PostgreSQL dans Azure Database.

  

Annulation de la migration à partir de l’interface CLI

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]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]

Par exemple :

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

Pour plus d’informations sur cette commande, utilisez le paramètre help :

 az postgres flexible-server migration update cancel -- help

La commande génère la sortie suivante :

---

Après la migration

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.

Contenu connexe

• Service de migration
• Effectuer une migration à partir de machines virtuelles locales et Azure
• Bonnes pratiques
• Problèmes connus et limitations
• Configuration réseau
• Validations de prémigration