Tutoriel : Migrer d’Azure Database pour PostgreSQL - Serveur unique vers Azure Database pour PostgreSQL - Serveur flexible avec le service de migration

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

Dans le portail Azure, vous pouvez migrer une instance d’Azure Database pour PostgreSQL - Serveur unique vers Azure Database pour PostgreSQL - Serveur flexible. Dans ce tutoriel, nous effectuons la migration d’un exemple de base de données d’un serveur unique Azure Database pour PostgreSQL vers un serveur flexible PostgreSQL à l’aide du portail Azure.

• 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

Portail

Vous pouvez faire la migration avec le portail Azure.

Hors connexion

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.

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.

Configurez votre instance de serveur flexible Azure Database pour PostgreSQL

• Créez le serveur flexible cible. Pour obtenir les étapes détaillées, consultez le guide de démarrage rapide Créer un serveur flexible Azure Database pour PostgreSQL avec le portail.

• Ajoutez à la liste d’autorisation les extensions dont les bibliothèques doivent être chargées au démarrage du serveur. Les extensions doivent impérativement être dans la liste d’autorisation avant le lancement d’une migration.

• Vérifiez s’il y a une asymétrie de la distribution des données dans les tables de base de données, par exemple, si la plupart des données sont présentes dans une seule ou quelques tables. En cas d’asymétrie, la migration peut être plus lente que prévu. Dans ce cas, la migration peut être accélérée en migrant la grande table en parallèle.

Configurer la tâche de migration

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

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

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

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

   

4. Sélectionnez le bouton Créer pour démarrer une migration de serveur unique vers un serveur flexible. S’il s’agit de la première fois que vous utilisez le service de migration, une grille vide s’affiche pour vous inviter à commencer votre première migration.

   

   Si vous avez déjà créé des migrations vers votre serveur flexible cible, la grille contient des informations sur les migrations qui ont été tentées vers cette cible à partir du serveur unique.

5. Sélectionnez le bouton Migrer à partir d’un serveur unique. Vous allez utiliser une série d’onglets basée sur un Assistant pour créer une migration vers cette cible de serveur flexible à partir de n’importe quelle source de serveur unique.

Vous pouvez également lancer le processus de migration à partir du serveur unique Azure Database pour PostgreSQL.

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

2. Lorsque vous sélectionnez le serveur unique, vous pouvez observer une bannière liée à la migration dans l’onglet Vue d’ensemble. Sélectionnez Migrer maintenant pour commencer.

   

3. Vous serez redirigé vers une page avec deux options. Si vous avez déjà créé un serveur flexible et que vous voulez l’utiliser comme cible, choisissez Sélectionner existant, puis sélectionnez les détails correspondants de l’abonnement, du groupe de ressources et du nom de serveur. Une fois les sélections effectuées, sélectionnez Accéder à l’Assistant Migration et passez aux instructions de la section Onglet Configuration de cette page.

   

4. Si vous choisissez de créer un serveur flexible, sélectionnez Créer, puis Accéder à l’Assistant Création. Cette action vous guide tout au long du processus de création du serveur flexible et déploie le serveur flexible.

   

Après avoir déployé le serveur flexible, suivez les étapes 3 à 5 de Configurer la tâche de migration.

Onglet Configuration

L’onglet Configuration apparaît en premier. Si vous ne l’avez pas fait, ajoutez à la liste d’autorisation les extensions nécessaires, comme indiqué dans Les extensions doivent impérativement être dans la liste d’autorisation avant le lancement d’une migration.

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.

Le type de serveur source indique la source. Dans ce cas, il s'agit d’Azure Database pour PostgreSQL - Serveur unique

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

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

La bonne pratique est de choisir l’option Valider ou Valider et migrer pour effectuer des validations de prémigration avant d’exécuter la migration.

Si la migration en ligne est sélectionnée,vous devez activer la réplication logique dans le serveur unique source. Si elle n’est pas activée, le service de migration active automatiquement la réplication logique sur le serveur unique source. Vous pouvez également configurer manuellement la réplication sous l’onglet Réplication dans le volet côté serveur unique en définissant le niveau de prise en charge de la réplication Azure sur Logique. Les deux approches redémarrent le serveur unique source.

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

Onglet Source

L’onglet Source vous invite à fournir les détails du serveur unique, qui est la source des bases de données.

Une fois que vous avez effectué les sélections Abonnement et Groupe de ressources, la liste déroulante des noms de serveur affiche le serveur unique sous ce groupe de ressources dans plusieurs régions. Sélectionnez la source à partir de laquelle vous souhaitez migrer les bases de données. Vous pouvez migrer des bases de données d’un serveur unique vers un serveur flexible cible dans la même région. Les migrations entre régions sont activées uniquement pour les serveurs en Inde, en Chine et aux Émirats arabes unis.

Une fois que vous avez choisi la source du serveur unique, les zones Emplacement, Version PostgreSQL et Nom de connexion de l’administrateur du serveur sont renseignées automatiquement. Le nom de connexion de l’administrateur du serveur est le nom d’utilisateur administrateur utilisé pour créer le serveur unique. Dans la zone Mot de passe, entrez le mot de passe de l’utilisateur administrateur. Le service de migration migre les bases de données du serveur unique en tant qu’utilisateur administrateur.

Après avoir renseigné tous les champs, sélectionnez le lien Se connecter à la source. Cette opération confirme que les détails du serveur source entrés sont corrects et que le serveur source est accessible.

Cliquez sur le bouton Suivant : Sélectionner la cible de migration pour continuer.

Onglet cible

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

Pour le Nom de connexion de l’administrateur du serveur, l’onglet affiche le nom d’utilisateur administrateur utilisé pour créer le serveur flexible cible. Entrez le mot de passe correspondant pour l’utilisateur administrateur. Une fois le mot de passe entré, sélectionnez le lien Se connecter à la cible. Cette opération permet de confirmer que les détails du serveur cible saisis sont corrects et que ce dernier est accessible.

Sélectionnez le bouton Suivant pour sélectionner les bases de données à migrer.

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

Sous cet onglet, il existe une liste de bases de données utilisateur à l’intérieur du serveur unique. Vous pouvez sélectionner et migrer jusqu’à huit bases de données en une seule tentative de migration. S’il existe plus de huit bases de données utilisateur, le processus de migration est répété entre les serveurs source et cible pour l’ensemble de bases de données suivant. Par défaut, les bases de données sélectionnées portant le même nom sur la cible sont remplacées.

Sélectionnez le bouton Suivant pour vérifier les détails.

Résumé

L'onglet Résumé résume tous les détails de la création de la validation ou de la migration. Passez en revue les détails et sélectionnez le bouton Démarrer.

Portail Monitorer la migration

Une fois que vous avez sélectionné le bouton Démarrer, une notification s’affiche quelques secondes plus tard pour indiquer que la validation ou la création de la migration est réussie. Vous êtes automatiquement redirigé vers la page Migration du serveur flexible. Il s’agit d’une nouvelle entrée pour la validation ou la migration récemment créée.

La grille qui affiche les migrations comporte les colonnes suivantes : Nom, État, Type de migration, Mode de migration, Serveur source, Type de serveur source, Bases de données, Heure de début et Durée. Les entrées sont affichées dans l’ordre décroissant de l’heure de début avec l’entrée la plus récente en haut.

Vous pouvez utiliser le bouton d’actualisation pour actualiser l’état de la validation ou de la migration. Vous pouvez également sélectionner le nom de la migration dans la grille pour afficher les détails associés.

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

Voyons comment monitorer les migrations pour chaque option de migration.

Valider

Une fois le sous-état PerformingPreRequisiteSteps terminé, la validation passe au sous-état de Validation en cours où les vérifications sont effectuées sur le serveur source et cible pour évaluer la préparation de la migration.

La validation passe à l’état Réussi si toutes les validations sont dans l’état Réussi ou Avertissement.

La grille de validation comporte les éléments suivants :

• Sections Détails de validation pour l’instance et Détails de validation pour les bases de données qui représentent les règles de validation utilisées pour vérifier la préparation de la migration.
• État de validation : représente le résultat de chaque règle et peut prendre l'une des trois valeurs suivantes
  • Réussi : si aucune erreur n’a été trouvée.
  • Échec : en cas d’erreurs de validation.
  • Avertissement : s’il existe des avertissements de validation.
• Durée : durée de l'opération de validation.
• Heure de début et de fin : heure de début et de fin de l'opération de validation au format UTC.

L'État de validation passe à l'état Échec si la validation comporte des erreurs. Sélectionnez la validation Nom de la validation ou Nom de la base de données qui a échoué. Un volet en éventail vous donne alors les détails et l’action corrective à exécuter pour éviter cette erreur.

Migrer

Quand 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. La durée de la migration dépend de la taille et de la forme des bases de données que vous migrez. La migration est rapide si les données sont principalement réparties uniformément dans toutes les tables. Les tailles de table inégales prennent un temps relativement plus long.

Lorsque vous sélectionnez n’importe laquelle de ces bases de données en cours de migration, un volet de ramification s’affiche. Il contient tous les chiffres des tables : copiées, mises en file d’attente, copie en cours et erreurs, à l’exception de l’état de migration de la base de données.

La migration passe à l’état Réussi dès que l’état Migration des données se termine correctement. En cas de problème au niveau de l’état Migration des données, la migration passe à l’état Échec.

Une fois la migration passée à l’état Réussi, la migration du schéma et des données de votre serveur unique vers votre serveur flexible cible est terminée. Vous pouvez utiliser le bouton Actualiser sur la page afin de confirmer.

Valider et migrer

Dans cette option, les validations sont effectuées en premier avant le démarrage 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 est terminée sans erreur, la migration démarre et le flux de travail passe au sous-état Migration des données.

Vous pouvez consulter les résultats de Validation et migration une fois l'opération terminée.

En ligne

Prérequis (en ligne)

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.

Configurer les paramètres de migration en ligne

Pour la migration en ligne, la prise en charge de la réplication doit être définie sur Logique dans les paramètres de réplication du serveur PostgreSQL source. En outre, les valeurs des paramètres de serveur max_wal_senders et max_replication_slots doivent être supérieures au nombre de bases de données à migrer. Les paramètres peuvent être définis dans le portail Azure sous Paramètres->Paramètres du serveur ou configurés dans la ligne de commande à l’aide des commandes suivantes :

• ALTER SYSTEM SET wal_level = logical;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate + 1 ;
• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1 ;

Vérifiez qu’il n’y a transaction durable. Les transactions durables n’autorisent pas la création d’emplacements de réplication. La création d’un emplacement de réplication réussit si toutes les transactions durables sont validées ou restaurées. Vous devez redémarrer le serveur PostgreSQL source après avoir rempli tous les prérequis de migration en ligne.

Remarque

Pour la migration en ligne avec un serveur unique Azure Database pour PostgreSQL, la prise en charge de la réplication Azure doit être définie sur Logique dans les paramètres de réplication de la page du serveur unique dans le portail Azure.

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.

• Le paramètre de serveur max_replication_slots doit être supérieur au nombre de bases de données qui doivent être migrées. Il peut être défini dans le portail Azure sous Paramètres->Paramètres du serveur ou configurés dans la ligne de commande à l’aide de la commande suivante :

• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1 ;

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	Publique	Aucune autre action n’est requise si la source est autorisée dans les règles de pare-feu de la cible.
Private	Public	Cette configuration n’est pas prise en charge ; utilisez pg_dump/pg_restore pour le transfert de données.
Public	Privé	Aucune autre action n’est requise si la source est autorisée 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.

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.

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.

Configurez votre instance de serveur flexible Azure Database pour PostgreSQL

• Créez le serveur flexible cible. Pour obtenir les étapes détaillées, consultez le guide de démarrage rapide Créer un serveur flexible Azure Database pour PostgreSQL avec le portail.

• Ajoutez à la liste d’autorisation les extensions dont les bibliothèques doivent être chargées au démarrage du serveur. Les extensions doivent impérativement être dans la liste d’autorisation avant le lancement d’une migration.

• Vérifiez s’il y a une asymétrie de la distribution des données dans les tables de base de données, par exemple, si la plupart des données sont présentes dans une seule ou quelques tables. En cas d’asymétrie, la migration peut être plus lente que prévu. Dans ce cas, la migration peut être accélérée en migrant la grande table en parallèle.

Configurer la tâche de migration

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

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

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

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

   

4. Sélectionnez le bouton Créer pour démarrer une migration de serveur unique vers un serveur flexible. S’il s’agit de la première fois que vous utilisez le service de migration, une grille vide s’affiche pour vous inviter à commencer votre première migration.

   

   Si vous avez déjà créé des migrations vers votre serveur flexible cible, la grille contient des informations sur les migrations qui ont été tentées vers cette cible à partir du serveur unique.

5. Sélectionnez le bouton Migrer à partir d’un serveur unique. Vous allez utiliser une série d’onglets basée sur un Assistant pour créer une migration vers cette cible de serveur flexible à partir de n’importe quelle source de serveur unique.

Vous pouvez également lancer le processus de migration à partir du serveur unique Azure Database pour PostgreSQL.

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

2. Lorsque vous sélectionnez le serveur unique, vous pouvez observer une bannière liée à la migration dans l’onglet Vue d’ensemble. Sélectionnez Migrer maintenant pour commencer.

   

3. Vous serez redirigé vers une page avec deux options. Si vous avez déjà créé un serveur flexible et que vous voulez l’utiliser comme cible, choisissez Sélectionner existant, puis sélectionnez les détails correspondants de l’abonnement, du groupe de ressources et du nom de serveur. Une fois les sélections effectuées, sélectionnez Accéder à l’Assistant Migration et passez aux instructions de la section Onglet Configuration de cette page.

   

4. Si vous choisissez de créer un serveur flexible, sélectionnez Créer, puis Accéder à l’Assistant Création. Cette action vous guide tout au long du processus de création du serveur flexible et déploie le serveur flexible.

   

Après avoir déployé le serveur flexible, suivez les étapes 3 à 5 de Configurer la tâche de migration.

Onglet Configuration

L’onglet Configuration apparaît en premier. Si vous ne l’avez pas fait, ajoutez à la liste d’autorisation les extensions nécessaires, comme indiqué dans Les extensions doivent impérativement être dans la liste d’autorisation avant le lancement d’une migration.

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.

Le type de serveur source indique la source. Dans ce cas, il s'agit d’Azure Database pour PostgreSQL - Serveur unique

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

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

La bonne pratique est de choisir l’option Valider ou Valider et migrer pour effectuer des validations de prémigration avant d’exécuter la migration.

Si la migration en ligne est sélectionnée,vous devez activer la réplication logique dans le serveur unique source. Si elle n’est pas activée, le service de migration active automatiquement la réplication logique sur le serveur unique source. Vous pouvez également configurer manuellement la réplication sous l’onglet Réplication dans le volet côté serveur unique en définissant le niveau de prise en charge de la réplication Azure sur Logique. Les deux approches redémarrent le serveur unique source.

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

Onglet Source

L’onglet Source vous invite à fournir les détails du serveur unique, qui est la source des bases de données.

Une fois que vous avez effectué les sélections Abonnement et Groupe de ressources, la liste déroulante des noms de serveur affiche le serveur unique sous ce groupe de ressources dans plusieurs régions. Sélectionnez la source à partir de laquelle vous souhaitez migrer les bases de données. Vous pouvez migrer des bases de données d’un serveur unique vers un serveur flexible cible dans la même région. Les migrations entre régions sont activées uniquement pour les serveurs en Inde, en Chine et aux Émirats arabes unis.

Une fois que vous avez choisi la source du serveur unique, les zones Emplacement, Version PostgreSQL et Nom de connexion de l’administrateur du serveur sont renseignées automatiquement. Le nom de connexion de l’administrateur du serveur est le nom d’utilisateur administrateur utilisé pour créer le serveur unique. Dans la zone Mot de passe, entrez le mot de passe de l’utilisateur administrateur. Le service de migration migre les bases de données du serveur unique en tant qu’utilisateur administrateur.

Après avoir renseigné tous les champs, sélectionnez le lien Se connecter à la source. Cette opération confirme que les détails du serveur source entrés sont corrects et que le serveur source est accessible.

Cliquez sur le bouton Suivant : Sélectionner la cible de migration pour continuer.

Onglet cible

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

Pour le Nom de connexion de l’administrateur du serveur, l’onglet affiche le nom d’utilisateur administrateur utilisé pour créer le serveur flexible cible. Entrez le mot de passe correspondant pour l’utilisateur administrateur. Une fois le mot de passe entré, sélectionnez le lien Se connecter à la cible. Cette opération permet de confirmer que les détails du serveur cible saisis sont corrects et que ce dernier est accessible.

Sélectionnez le bouton Suivant pour sélectionner les bases de données à migrer.

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

Sous cet onglet, il existe une liste de bases de données utilisateur à l’intérieur du serveur unique. Vous pouvez sélectionner et migrer jusqu’à huit bases de données en une seule tentative de migration. S’il existe plus de huit bases de données utilisateur, le processus de migration est répété entre les serveurs source et cible pour l’ensemble de bases de données suivant. Par défaut, les bases de données sélectionnées portant le même nom sur la cible sont remplacées.

Sélectionnez le bouton Suivant pour vérifier les détails.

Résumé

L'onglet Résumé résume tous les détails de la création de la validation ou de la migration. Passez en revue les détails et sélectionnez le bouton Démarrer.

Monitorer la migration avec le portail Azure

Une fois que vous avez sélectionné le bouton Démarrer, une notification s’affiche quelques secondes plus tard pour indiquer que la validation ou la création de la migration est réussie. Vous êtes automatiquement redirigé vers la page Migration du serveur flexible. Il s’agit d’une nouvelle entrée pour la validation ou la migration récemment créée.

La grille qui affiche les migrations comporte les colonnes suivantes : Nom, État, Type de migration, Mode de migration, Serveur source, Type de serveur source, Bases de données, Heure de début et Durée. Les entrées sont affichées dans l’ordre décroissant de l’heure de début avec l’entrée la plus récente en haut.

Vous pouvez utiliser le bouton d’actualisation pour actualiser l’état de la validation ou de la migration. Vous pouvez également sélectionner le nom de la migration dans la grille pour afficher les détails associés.

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

Voyons comment monitorer les migrations pour chaque option de migration.

Valider

Une fois le sous-état PerformingPreRequisiteSteps terminé, la validation passe au sous-état de Validation en cours où les vérifications sont effectuées sur le serveur source et cible pour évaluer la préparation de la migration.

La validation passe à l’état Réussi si toutes les validations sont dans l’état Réussi ou Avertissement.

La grille de validation comporte les éléments suivants :

• Sections Détails de validation pour l’instance et Détails de validation pour les bases de données qui représentent les règles de validation utilisées pour vérifier la préparation de la migration.
• État de validation : représente le résultat de chaque règle et peut prendre l'une des trois valeurs suivantes
  • Réussi : si aucune erreur n’a été trouvée.
  • Échec : en cas d’erreurs de validation.
  • Avertissement : s’il existe des avertissements de validation.
• Durée : durée de l'opération de validation.
• Heure de début et de fin : heure de début et de fin de l'opération de validation au format UTC.

L'État de validation passe à l'état Échec si la validation comporte des erreurs. Sélectionnez la validation Nom de la validation ou Nom de la base de données qui a échoué. Un volet en éventail vous donne alors les détails et l’action corrective à exécuter pour éviter cette erreur.

Migrer

Quand 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. La durée de la migration dépend de la taille et de la forme des bases de données que vous migrez. La migration est rapide si les données sont principalement réparties uniformément dans toutes les tables. Les tailles de table inégales prennent un temps relativement plus long.

Lorsque vous sélectionnez n’importe laquelle de ces bases de données en cours de migration, un volet de ramification s’affiche. Il contient tous les chiffres des tables : copiées, mises en file d’attente, copie en cours et erreurs, à l’exception de l’état de migration de la base de données.

La migration passe à l’état Réussi dès que l’état Migration des données se termine correctement. En cas de problème au niveau de l’état Migration des données, la migration passe à l’état Échec.

Une fois la migration passée à l’état Réussi, la migration du schéma et des données de votre serveur unique vers votre serveur flexible cible est terminée. Vous pouvez utiliser le bouton Actualiser sur la page afin de confirmer.

Valider et migrer

Dans cette option, les validations sont effectuées en premier avant le démarrage 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 est terminée sans erreur, la migration démarre et le flux de travail passe au sous-état Migration des données.

Vous pouvez consulter les résultats de Validation et migration une fois l'opération terminée.

Migration à basculement

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

Avant de lancer le basculement, vérifiez que :

• Les écritures dans la source sont arrêtées : la valeur du paramètre Latency (minutes) est 0 ou proche de 0. Les informations de Latency (minutes) peuvent être obtenues à partir de l’écran des détails de la migration, comme illustré ci-dessous :

Le paramètre Latency (minutes) indique quand la cible a été synchronisée pour la dernière fois avec la source. Par exemple, pour la base de données Orders ci-dessus, il s’agit de 0,33333. Cela signifie que les modifications qui se sont produites à la source au cours des 18 dernières secondes (0,3 minute) ne sont pas encore synchronisées avec la cible pour la base de données Orders. À ce stade, les écritures dans la source peuvent être arrêtées et le basculement peut être lancé. Si le trafic est important au niveau de la source, nous vous recommandons d’arrêter d’abord les écritures afin que Latency (minutes) puisse atteindre une valeur proche de 0, puis de lancer le 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 latence autre que zéro, la réplication s’arrête jusqu’à ce point dans le temps. Toutes les données de la source jusqu’au point de basculement sont ensuite appliquées à la cible. Si, par exemple, la latence est de 15 minutes au point de basculement, tous les changements de données des 15 dernières minutes sont appliqués à la cible. La durée dépend du backlog des changements survenus au cours des 15 dernières minutes. Par conséquent, nous vous recommandons d’attendre que la latence atteigne zéro ou une valeur proche de zéro avant de déclencher le basculement.

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

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.

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.
• Terminé : la migration s’est terminée.

Annuler la migration dans le 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 restaure toutes les modifications apportées par le service de migration sur votre serveur cible.

INTERFACE DE LIGNE DE COMMANDE

Vous pouvez effectuer une migration avec Azure CLI.

Hors connexion

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.

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.

Bien démarrer

1. Si vous débutez avec Microsoft Azure, créez un compte pour évaluer les offres.

2. Installez la dernière version d’Azure CLI pour votre système d’exploitation à partir de la page d’installation d’Azure CLI.

   Si Azure CLI est déjà installé, vérifiez la version à l’aide de la commande az version. La version doit être 2.50.0 ou ultérieure pour pouvoir utiliser les commandes CLI de migration. Si ce n’est pas le cas, mettez à jour votre version d’Azure CLI.

3. Exécutez la commande az login :

   az login
   

   Une fenêtre de navigateur s’ouvre avec la page de connexion Azure. Fournissez vos informations d’identification Azure pour réussir l’authentification. Pour d’autres méthodes de connexion à Azure CLI, référez-vous à cet article.

Commandes d’interface CLI pour la migration (hors connexion)

Le service de migration comprend des commandes d’interface CLI faciles à utiliser pour effectuer les tâches liées à la migration. Toutes les commandes d’interface de ligne de commande commencent par az postgres flexible-server migration. Les extensions doivent impérativement être ajoutées à la liste d’autorisation avant le lancement d’une migration.

Pour obtenir de l’aide sur la compréhension des options associées à une commande et avec l’encadrement de la syntaxe appropriée, vous pouvez utiliser le paramètre help :

az postgres flexible-server migration --help

La commande ci-dessus génère la sortie suivante :

La sortie répertorie les commandes de migration prises en charge, ainsi que leurs actions. Examinons en détail ces commandes.

Créer une migration à l’aide d’Azure CLI

La commande create permet de créer une migration d’un serveur source vers un serveur cible :

az postgres flexible-server migration create -- help

La commande ci-dessus génère le résultat suivant :

Elle répertorie les arguments attendus et fournit un exemple de syntaxe pour créer une migration réussie du serveur source vers le serveur cible. Voici la commande CLI pour créer une migration :

az postgres flexible-server migration create [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]
                                            [--migration-mode]
                                            [--properties]

Paramètre	Description
subscription	ID d’abonnement du serveur flexible cible.
resource-group	Groupe de ressources du serveur flexible cible.
name	Nom du serveur flexible 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.
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.
properties	Chemin d’accès absolu à un fichier JSON qui contient les informations sur le serveur unique source.

Par exemple :

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

L’argument migration-name dans la commande create est utilisé dans d’autres commandes CLI, comme update, delete et show.. Il identifie de manière unique la tentative de migration dans les actions correspondantes de toutes ces commandes.

Enfin, la commande create requiert qu’un fichier JSON soit transmis dans son argument properties.

La structure du code JSON est la suivante :

{
"properties": {
 "sourceDbServerResourceId":"/subscriptions/<subscriptionid>/resourceGroups/<src_ rg_name>/providers/Microsoft.DBforPostgreSQL/servers/<source server name>",
"secretParameters": {
    "adminCredentials":
    {
      "sourceServerPassword": "<password>",
      "targetServerPassword": "<password>"
    },
   "sourceServerUserName": "<username>@<servername>",
   "targetServerUserName": "<username>"
},

"dbsToMigrate":
   [
   "<db1>","<db2>"
   ],

"overwriteDbsInTarget":"true"

}
}

Les paramètres create dans le format de fichier JSON sont les suivants :

Paramètre	Type	Description
sourceDbServerResourceId	Obligatoire	Ce paramètre est l’ID de ressource de la source du serveur unique et il est obligatoire.
adminCredentials	Obligatoire	Ce paramètre répertorie les mots de passe des utilisateurs administrateurs pour la source de serveur unique et la cible de serveur flexible. Ces mots de passe permettent d’effectuer une authentification auprès des serveurs source et cible.
sourceServerUserName	Requis	La valeur par défaut est l’utilisateur administrateur utilisé pour créer un serveur unique, et le mot de passe fourni est utilisé pour l’authentification avec 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 source qui effectue la migration. Cet utilisateur doit avoir les privilèges et la propriété nécessaires sur les objets de base de données impliqués dans la migration, et doit être membre du rôle azure_pg_admin.
targetServerUserName	Requis	La valeur par défaut est l’utilisateur administrateur utilisé pour créer un serveur flexible, et le mot de passe fourni est utilisé pour l’authentification avec 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 utilisé pour effectuer la migration. Cet utilisateur doit être membre des rôles azure_pg_admin, pg_read_all_settings, pg_read_all_stats,pg_stat_scan_tables et doit avoir le rôle Créer un rôle, créer une base de données.
dbsToMigrate	Requis	Spécifiez la liste des bases de données que vous souhaitez migrer vers le serveur flexible. Seules les bases de données utilisateur sont migrées. Les bases de données système ou les bases de données de modèle comme template0 et template1 ne sont pas migrées.
overwriteDbsInTarget	Requis	Quand la valeur est true, si le serveur cible a déjà une base de données du même nom que celle que vous essayez de migrer, le service de migration remplace automatiquement la base de données.
SetupLogicalReplicationOnSourceDBIfNeeded	Facultatif	Vous pouvez automatiquement activer la réplication logique sur le serveur source en définissant cette propriété sur true. Ce changement de paramètres du serveur nécessite un redémarrage du serveur avec un temps d’arrêt de 2 à 3 minutes.
SourceDBServerFullyQualifiedDomainName	Facultatif	Utilisez-le lorsqu’un serveur DNS personnalisé est utilisé pour la résolution de noms d’un réseau virtuel. Fournissez le nom de domaine complet de la source du serveur unique en fonction du serveur DNS personnalisé pour cette propriété.
TargetDBServerFullyQualifiedDomainName	Facultatif	Utilisez-le lorsqu’un serveur DNS personnalisé est utilisé pour la résolution de noms au sein d’un réseau virtuel. Fournissez le nom de domaine complet de la cible du serveur flexible en fonction du serveur DNS personnalisé. SourceDBServerFullyQualifiedDomainName et TargetDBServerFullyQualifiedDomainName sont inclus dans le cadre du JSON uniquement dans les rares cas où un serveur DNS personnalisé est utilisé pour la résolution de noms au lieu d’un DNS fourni par Azure. Sinon, n’incluez pas ces paramètres dans le fichier JSON.

Notez ces points importants pour la réponse de la commande :

• Dès que la commande create est déclenchée, la migration passe à l’état InProgress et au sous-état PerformingPreRequisiteSteps. Le workflow de migration prend quelques minutes pour déployer l’infrastructure de migration, et configurer les connexions entre la source et la cible.
• Dès que le sous-état PerformingPreRequisiteSteps est terminé, la migration passe au sous-état Migrating Data,, où le clonage/la copie des bases de données ont lieu.
• Chaque base de données migrée a sa propre section contenant tous les détails de migration tels 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 Migrating Data se termine dépend de la taille des bases de données migrées.
• La migration passe à l’état Succeeded dès que le sous-état Migrating Data s’est correctement terminé. S’il y a un problème au niveau du sous-état Migrating Data, la migration passe à l’état Failed.

Configurer la réplication

Si la migration en ligne est sélectionnée,vous devez activer la réplication logique dans le serveur unique source. Si elle n’est pas activée, le service de migration active automatiquement la réplication logique sur le serveur unique source quand le paramètre SetupLogicalReplicationOnSourceDBIfNeeded est passé avec la valeur true dans le fichier JSON associé. La réplication peut également être configurée manuellement sur la source après le démarrage de la migration, avec la commande ci-dessous. Les deux approches d’activation de la réplication logique entraînent un redémarrage du serveur unique source.

Par exemple :

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --setup-replication

Cette commande est nécessaire pour faire avancer la migration lorsque le serveur flexible attend dans l’état WaitingForLogicalReplicationSetupRequestOnSourceDB.

Pour effectuer une migration en ligne dans l’une des régions ci-dessus, utilisez :

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

Lister les migrations

La commande list répertorie toutes les tentatives de migration effectuées sur la cible de serveur flexible :

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

Le paramètre filter a deux options :

• Active : répertorie les tentatives de migration actives actuelles (en cours) vers le serveur cible. Cela n’inclut pas les migrations ayant échoué ou réussi, ou ayant été annulées.
• All : répertorie toutes les tentatives de migration vers le serveur cible. Cela inclut les migrations actives et passées indépendamment de l’état.

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

az postgres flexible-server migration list -- help

Surveiller la migration

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]

Le paramètre migration_name est le nom attribué à la migration pendant la commande create. Voici un instantané de l’exemple de réponse à partir de la commande CLI pour afficher les détails :

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

 az postgres flexible-server migration show -- help

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

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

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.
CompletingMigration	Le basculement de la migration est en cours.
Completed	Le basculement a réussi et la migration est terminée.

En ligne

Prérequis (en ligne)

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.

Configurer les paramètres de migration en ligne

Pour la migration en ligne, la prise en charge de la réplication doit être définie sur Logique dans les paramètres de réplication du serveur PostgreSQL source. En outre, les valeurs des paramètres de serveur max_wal_senders et max_replication_slots doivent être supérieures au nombre de bases de données à migrer. Les paramètres peuvent être définis dans le portail Azure sous Paramètres->Paramètres du serveur ou configurés dans la ligne de commande à l’aide des commandes suivantes :

• ALTER SYSTEM SET wal_level = logical;
• ALTER SYSTEM SET max_wal_senders = number of databases to migrate + 1 ;
• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1 ;

Vérifiez qu’il n’y a transaction durable. Les transactions durables n’autorisent pas la création d’emplacements de réplication. La création d’un emplacement de réplication réussit si toutes les transactions durables sont validées ou restaurées. Vous devez redémarrer le serveur PostgreSQL source après avoir rempli tous les prérequis de migration en ligne.

Remarque

Pour la migration en ligne avec un serveur unique Azure Database pour PostgreSQL, la prise en charge de la réplication Azure doit être définie sur Logique dans les paramètres de réplication de la page du serveur unique dans le portail Azure.

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.

• Le paramètre de serveur max_replication_slots doit être supérieur au nombre de bases de données qui doivent être migrées. Il peut être défini dans le portail Azure sous Paramètres->Paramètres du serveur ou configurés dans la ligne de commande à l’aide de la commande suivante :

• ALTER SYSTEM SET max_replication_slots = number of databases to migrate + 1 ;

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	Publique	Aucune autre action n’est requise si la source est autorisée dans les règles de pare-feu de la cible.
Private	Public	Cette configuration n’est pas prise en charge ; utilisez pg_dump/pg_restore pour le transfert de données.
Public	Privé	Aucune autre action n’est requise si la source est autorisée 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.

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.

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.

Bien démarrer

1. Si vous débutez avec Microsoft Azure, créez un compte pour évaluer les offres.

2. Installez la dernière version d’Azure CLI pour votre système d’exploitation à partir de la page d’installation d’Azure CLI.

   Si Azure CLI est déjà installé, vérifiez la version à l’aide de la commande az version. La version doit être 2.50.0 ou ultérieure pour pouvoir utiliser les commandes CLI de migration. Si ce n’est pas le cas, mettez à jour votre version d’Azure CLI.

3. Exécutez la commande az login :

   az login
   

   Une fenêtre de navigateur s’ouvre avec la page de connexion Azure. Fournissez vos informations d’identification Azure pour réussir l’authentification. Pour d’autres méthodes de connexion à Azure CLI, référez-vous à cet article.

Commandes d’interface CLI pour la migration (en ligne)

Le service de migration comprend des commandes d’interface CLI faciles à utiliser pour effectuer les tâches liées à la migration. Toutes les commandes d’interface de ligne de commande commencent par az postgres flexible-server migration. Les extensions doivent impérativement être ajoutées à la liste d’autorisation avant le lancement d’une migration.

Pour obtenir de l’aide sur la compréhension des options associées à une commande et avec l’encadrement de la syntaxe appropriée, vous pouvez utiliser le paramètre help :

az postgres flexible-server migration --help

La commande ci-dessus génère la sortie suivante :

La sortie répertorie les commandes de migration prises en charge, ainsi que leurs actions. Examinons en détail ces commandes.

Créer une migration à l’aide d’Azure CLI

La commande create permet de créer une migration d’un serveur source vers un serveur cible :

az postgres flexible-server migration create -- help

La commande ci-dessus génère le résultat suivant :

Elle répertorie les arguments attendus et fournit un exemple de syntaxe pour créer une migration réussie du serveur source vers le serveur cible. Voici la commande CLI pour créer une migration :

az postgres flexible-server migration create [--subscription]
                                            [--resource-group]
                                            [--name]
                                            [--migration-name]
                                            [--migration-mode]
                                            [--properties]

Paramètre	Description
subscription	ID d’abonnement du serveur flexible cible.
resource-group	Groupe de ressources du serveur flexible cible.
name	Nom du serveur flexible 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.
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.
properties	Chemin d’accès absolu à un fichier JSON qui contient les informations sur le serveur unique source.

Par exemple :

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

L’argument migration-name dans la commande create est utilisé dans d’autres commandes CLI, comme update, delete et show.. Il identifie de manière unique la tentative de migration dans les actions correspondantes de toutes ces commandes.

Enfin, la commande create requiert qu’un fichier JSON soit transmis dans son argument properties.

La structure du code JSON est la suivante :

{
"properties": {
 "sourceDbServerResourceId":"/subscriptions/<subscriptionid>/resourceGroups/<src_ rg_name>/providers/Microsoft.DBforPostgreSQL/servers/<source server name>",
"secretParameters": {
    "adminCredentials":
    {
      "sourceServerPassword": "<password>",
      "targetServerPassword": "<password>"
    },
   "sourceServerUserName": "<username>@<servername>",
   "targetServerUserName": "<username>"
},

"dbsToMigrate":
   [
   "<db1>","<db2>"
   ],

"overwriteDbsInTarget":"true"

}
}

Les paramètres create dans le format de fichier JSON sont les suivants :

Paramètre	Type	Description
sourceDbServerResourceId	Obligatoire	Ce paramètre est l’ID de ressource de la source du serveur unique et il est obligatoire.
adminCredentials	Obligatoire	Ce paramètre répertorie les mots de passe des utilisateurs administrateurs pour la source de serveur unique et la cible de serveur flexible. Ces mots de passe permettent d’effectuer une authentification auprès des serveurs source et cible.
sourceServerUserName	Requis	La valeur par défaut est l’utilisateur administrateur utilisé pour créer un serveur unique, et le mot de passe fourni est utilisé pour l’authentification avec 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 source qui effectue la migration. Cet utilisateur doit avoir les privilèges et la propriété nécessaires sur les objets de base de données impliqués dans la migration, et doit être membre du rôle azure_pg_admin.
targetServerUserName	Requis	La valeur par défaut est l’utilisateur administrateur utilisé pour créer un serveur flexible, et le mot de passe fourni est utilisé pour l’authentification avec 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 utilisé pour effectuer la migration. Cet utilisateur doit être membre des rôles azure_pg_admin, pg_read_all_settings, pg_read_all_stats,pg_stat_scan_tables et doit avoir le rôle Créer un rôle, créer une base de données.
dbsToMigrate	Requis	Spécifiez la liste des bases de données que vous souhaitez migrer vers le serveur flexible. Seules les bases de données utilisateur sont migrées. Les bases de données système ou les bases de données de modèle comme template0 et template1 ne sont pas migrées.
overwriteDbsInTarget	Requis	Quand la valeur est true, si le serveur cible a déjà une base de données du même nom que celle que vous essayez de migrer, le service de migration remplace automatiquement la base de données.
SetupLogicalReplicationOnSourceDBIfNeeded	Facultatif	Vous pouvez automatiquement activer la réplication logique sur le serveur source en définissant cette propriété sur true. Ce changement de paramètres du serveur nécessite un redémarrage du serveur avec un temps d’arrêt de 2 à 3 minutes.
SourceDBServerFullyQualifiedDomainName	Facultatif	Utilisez-le lorsqu’un serveur DNS personnalisé est utilisé pour la résolution de noms d’un réseau virtuel. Fournissez le nom de domaine complet de la source du serveur unique en fonction du serveur DNS personnalisé pour cette propriété.
TargetDBServerFullyQualifiedDomainName	Facultatif	Utilisez-le lorsqu’un serveur DNS personnalisé est utilisé pour la résolution de noms au sein d’un réseau virtuel. Fournissez le nom de domaine complet de la cible du serveur flexible en fonction du serveur DNS personnalisé. SourceDBServerFullyQualifiedDomainName et TargetDBServerFullyQualifiedDomainName sont inclus dans le cadre du JSON uniquement dans les rares cas où un serveur DNS personnalisé est utilisé pour la résolution de noms au lieu d’un DNS fourni par Azure. Sinon, n’incluez pas ces paramètres dans le fichier JSON.

Notez ces points importants pour la réponse de la commande :

• Dès que la commande create est déclenchée, la migration passe à l’état InProgress et au sous-état PerformingPreRequisiteSteps. Le workflow de migration prend quelques minutes pour déployer l’infrastructure de migration, et configurer les connexions entre la source et la cible.
• Dès que le sous-état PerformingPreRequisiteSteps est terminé, la migration passe au sous-état Migrating Data,, où le clonage/la copie des bases de données ont lieu.
• Chaque base de données migrée a sa propre section contenant tous les détails de migration tels 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 Migrating Data se termine dépend de la taille des bases de données migrées.
• La migration passe à l’état Succeeded dès que le sous-état Migrating Data s’est correctement terminé. S’il y a un problème au niveau du sous-état Migrating Data, la migration passe à l’état Failed.

Configurer la réplication

Si la migration en ligne est sélectionnée,vous devez activer la réplication logique dans le serveur unique source. Si elle n’est pas activée, le service de migration active automatiquement la réplication logique sur le serveur unique source quand le paramètre SetupLogicalReplicationOnSourceDBIfNeeded est passé avec la valeur true dans le fichier JSON associé. La réplication peut également être configurée manuellement sur la source après le démarrage de la migration, avec la commande ci-dessous. Les deux approches d’activation de la réplication logique entraînent un redémarrage du serveur unique source.

Par exemple :

az postgres flexible-server migration update --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name CLIMigrationExample --setup-replication

Cette commande est nécessaire pour faire avancer la migration lorsque le serveur flexible attend dans l’état WaitingForLogicalReplicationSetupRequestOnSourceDB.

Pour effectuer une migration en ligne dans l’une des régions ci-dessus, utilisez :

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

Lister les migrations

La commande list répertorie toutes les tentatives de migration effectuées sur la cible de serveur flexible :

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

Le paramètre filter a deux options :

• Active : répertorie les tentatives de migration actives actuelles (en cours) vers le serveur cible. Cela n’inclut pas les migrations ayant échoué ou réussi, ou ayant été annulées.
• All : répertorie toutes les tentatives de migration vers le serveur cible. Cela inclut les migrations actives et passées indépendamment de l’état.

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

az postgres flexible-server migration list -- help

Surveiller la migration

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]

Le paramètre migration_name est le nom attribué à la migration pendant la commande create. Voici un instantané de l’exemple de réponse à partir de la commande CLI pour afficher les détails :

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

 az postgres flexible-server migration show -- help

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

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

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.
CompletingMigration	Le basculement de la migration est en cours.
Completed	Le basculement a réussi et la migration est terminée.

Basculement de la migration

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

Par exemple :

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

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

• Les écritures vers la source sont arrêtées (le paramètre latency descend à 0 ou proche de 0).

Le paramètre latency indique quand la cible a été synchronisée pour la dernière fois avec la source. Par exemple, les valeurs sont ici 201 et 202 pour les deux bases de données, comme illustré dans l’image ci-dessous. Cela signifie que les modifications qui se sont produites à la source au cours des 200 dernières secondes ne sont pas encore synchronisées avec la cible. À ce stade, les écritures dans la source peuvent être arrêtées et le basculement peut être lancé. Si le trafic est important au niveau de la source, nous vous recommandons d’arrêter d’abord les écritures afin que Latency puisse atteindre une valeur proche de 0, puis de lancer le basculement. L’opération de basculement applique tous les changements en attente de la source vers la cible, et effectue la migration. Si vous déclenchez un « basculement » avec un paramètre Latency différent de zéro, la réplication s’arrête jusqu’à ce point dans le temps. Toutes les données de la source jusqu’au point de basculement sont ensuite appliquées à la cible. Si, par exemple, la latence est de 15 minutes au point de basculement, tous les changements de données des 15 dernières minutes sont appliqués à la cible. La durée dépend du backlog des changements survenus au cours des 15 dernières minutes. Par conséquent, nous vous recommandons d’attendre que la latence atteigne zéro ou une valeur proche de zéro avant de déclencher le basculement. Les informations latency peuvent être obtenues à l’aide de la commande de migration show . Voici un instantané de la migration avant de lancer le basculement :

Une fois le basculement lancé, toutes les transactions qui se sont produites pendant la copie de base sont copiées séquentiellement sur la cible, et la migration est terminée.

Si le basculement échoue, la migration passe à l’état Failed.

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

 az postgres flexible-server migration update -- help

Annuler la migration avec 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 d’AWS RDS
• Bonnes pratiques
• Problèmes connus et limitations
• Configuration réseau
• Validations de prémigration