Tutoriel : Migrer du serveur unique au serveur flexible Azure Database pour PostgreSQL à l’aide du 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 aux prérequis suivants, qui s’appliquent aux scénarios de migration hors ligne.

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 :

• Le serveur flexible Azure Database pour PostgreSQL doit être déployé et correctement configuré dans Azure avant de commencer le processus de 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.

• Lors de la migration entre les versions de PostgreSQL (majeures ou mineures), assurez-vous de la compatibilité entre votre base de données et votre application en recherchant dans les notes de publication de potentiels changements cassants.

Configuration du réseau

La configuration du réseau est cruciale pour que le service de migration fonctionne correctement. Vérifiez que le serveur PostgreSQL source peut communiquer avec le serveur Azure Database pour PostgreSQL cible. Les configurations réseau suivantes sont essentielles pour une migration réussie.

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

Activer les extensions

Pour garantir la réussite de la migration à l’aide du service de migration dans Azure Database pour PostgreSQL, il peut être nécessaire de vérifier les extensions de votre instance PostgreSQL source. Les extensions fournissent des fonctionnalités qui peuvent être requises pour votre application. Veillez à vérifier les extensions sur l’instance PostgreSQL source avant de lancer le processus de migration.

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

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

Remarque

Un redémarrage est nécessaire quand vous apportez des modifications au paramètre shared_preload_libraries.

Vérifier les paramètres du 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 le serveur flexible Azure Database pour PostgreSQL pour appliquer la nouvelle configuration.

Important

Modifiez le paramètre de serveur password_encryption sur votre serveur flexible de SCRAM-SHA-256 à MD5 avant de lancer la migration. Cela est essentiel pour que les informations d’identification existantes sur le serveur unique fonctionnent sur votre serveur flexible.

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

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

• Extensions de liste d'autorisation 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 vitesse de 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. Vous utilisez une série d’onglets aidée par un Assistant pour créer une migration vers cette cible de serveur flexible depuis différentes sources possibles. Par défaut, le Type de serveur source est défini sur Serveur unique Azure Database pour PostgreSQL, qui est celui qui nous intéresse dans ce scénario.

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 et sélectionnez les détails correspondants pour Abonnement, Groupe de ressources et Nom du serveur. Une fois les sélections effectuées, sélectionnez Accéder à l’Assistant de migration et suivez les instructions de la section Configuration.

   

4. Si vous choisissez de créer un nouveau serveur flexible, sélectionnez Créer nouveau, puis Accéder à l’Assistant de 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.

Programme d’installation

L’onglet Configuration apparaît en premier. Si vous ne l’avez pas encore fait, établissez une liste d'autorisations pour les extensions nécessaires, comme décrit dans Configurer votre serveur flexible Azure Database pour PostgreSQL, avant de lancer une migration.

Le nom de la migration est l’identificateur unique de chaque migration vers cette cible de serveur flexible. Ce champ n’accepte que des caractères alphanumériques et n’accepte aucun caractère spécial à l’exception du tiret bas (_) et du trait d’union (-). Le nom doit commencer par un caractère alphanumérique. Le nom d’un serveur cible doit également être unique, car deux migrations vers le même serveur flexible cible ne peuvent 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

Option de migration vous permet de réaliser 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 la migration.
• 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.

Mode de migration vous permet de choisir entre une migration en ligne et une migration hors ligne. Dans ce cas, il doit être défini sur Hors ligne.

Sélectionnez le bouton Suivant : sélectionner le serveur de runtime.

Serveur d’exécution

Le serveur d’exécution de migration est une fonctionnalité spécialisée intégrée au service de migration dans Azure Database pour PostgreSQL, conçu pour agir en tant que serveur intermédiaire pendant la migration. Il s’agit d’une instance de serveur flexible Azure Database pour PostgreSQL distincte qui n’est pas le serveur cible, mais utilisé pour faciliter la migration des bases de données à partir d’un environnement source accessible uniquement via un réseau privé.

Pour plus d’informations sur le serveur d’exécution, visitez la page du Serveur d’exécution de migration.

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

Se connecter à la source

La section Source vous invite à fournir des informations sur le 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 Serveur unique, les zones Emplacement et Version PostgreSQL sont remplies automatiquement. Veillez à fournir les informations d’identification d’un rôle d’administrateur, car elles sont nécessaires pour que le service de migration migre correctement les bases de données.

Le champ Nom de domaine complet/IP personnalisé est facultatif et peut être utilisé quand la source se trouve derrière un serveur DNS personnalisé ou a des espaces de noms DNS personnalisés, ce qui la rend accessible seulement via des noms de domaine complets (FQDN) ou des adresses IP spécifiques. Par exemple, il peut s’agir d’entrées telles que singleserver.example.com, 198.1.0.2 ou d’un nom de domaine complet PostgreSQL comme singleserver.postgres.database.azure.com si le serveur DNS personnalisé contient la zone DNS postgres.database.azure.com ou transfère des requêtes pour cette zone à 168.63.129.16, où le nom de domaine complet est résolu dans la zone DNS publique ou privée Azure.

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.

Sélectionner la cible de migration

La section Sélectionner la cible de migration affiche les métadonnées du serveur flexible cible, comme Abonnement, Groupe de ressources, Nom du serveur, Emplacement et Version PostgreSQL.

Le champ Nom de domaine complet/IP personnalisé est facultatif et peut être utilisé quand la cible se trouve derrière un serveur DNS personnalisé ou a des espaces de noms DNS personnalisés, ce qui la rend accessible seulement via des noms de domaine complets (FQDN) ou des adresses IP spécifiques. Par exemple, il peut s’agir d’entrées telles que flexibleserver.example.com, 198.1.0.2 ou d’un nom de domaine complet PostgreSQL comme flexibleserver.postgres.database.azure.com si le serveur DNS personnalisé contient la zone DNS postgres.database.azure.com ou transfère des requêtes pour cette zone à 168.63.129.16, où le nom de domaine complet est résolu dans la zone DNS publique ou privée Azure.

Choisissez les valeurs appropriées pour Méthode d’authentification et tous les champs associés à l’authentification. Vérifiez que l’identité fournie est celle de l’utilisateur administrateur sur le serveur cible. Après avoir rempli toutes les informations requises, 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 : sélectionner la ou les bases de données pour la migration pour sélectionner les bases de données à migrer.

Sélectionner une ou plusieurs 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. Les bases de données sélectionnées qui existent sur le serveur cible avec exactement les mêmes noms sont remplacées.

Sélectionnez le bouton Suivant : résumé 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 informations et sélectionnez le bouton Démarrer la validation et la migration.

Portail Monitorer la migration

Une fois la migration démarrée, une notification s’affiche pour indiquer que la création de la validation ou 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, Mode de migration, Type de migration, Serveur source, Type du 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 Actualiser pour actualiser l’état de la validation ou de la migration.

Vous pouvez également sélectionner le nom d’une migration particulière 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 analyser 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 informations suivantes :

• 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.
• Nom de la validation : nom de chaque règle de validation spécifique.
• État de la 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 (UTC) et Heure de fin (UTC) : 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

Lorsque le sous-état PerformingPreRequisiteSteps est terminé, la migration passe au sous-état Migration des données, lorsque le clonage ou la copie des bases de données ont 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 nombres de tables (copiées, mises en file d’attente, copie en cours et erreurs) ainsi que 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 actualiser la page pour vérifier la progression.

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.

Pour éviter que la migration en ligne ne manque d’espace de stockage pour les journaux, assurez-vous que vous disposez de suffisamment d’espace de table à l’aide d’un disque managé approvisionné. Pour ce faire, désactivez le paramètre serveur azure.enable_temp_tablespaces_on_local_ssd sur le serveur flexible pendant la durée de la migration, et rétablissez-le dans son état d’origine après la migration.

Configurer la 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 ;

• Lors de la migration entre les versions de PostgreSQL (majeures ou mineures), assurez-vous de la compatibilité entre votre base de données et votre application en recherchant dans les notes de publication de potentiels changements cassants.

Important

Modifiez le paramètre de serveur password_encryption sur votre serveur flexible de SCRAM-SHA-256 à MD5 avant de lancer la migration. Cela est essentiel pour que les informations d’identification existantes sur le serveur unique fonctionnent sur votre serveur flexible.

Configurer le réseau

La configuration du réseau est cruciale pour que le service de migration fonctionne correctement. Vérifiez que le serveur PostgreSQL source peut communiquer avec le serveur Azure Database pour PostgreSQL cible. Les configurations réseau suivantes sont essentielles pour une migration réussie.

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

Activer les extensions

Pour garantir la réussite de la migration à l’aide du service de migration dans Azure Database pour PostgreSQL, il peut être nécessaire de vérifier les extensions de votre instance PostgreSQL source. Les extensions fournissent des fonctionnalités qui peuvent être requises pour votre application. Veillez à vérifier les extensions sur l’instance PostgreSQL source avant de lancer le processus de migration.

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

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

Remarque

Un redémarrage est nécessaire quand vous apportez des modifications au paramètre shared_preload_libraries.

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.

Remarque

Certaines limitations s’appliquent à la migration en ligne qui sont documentées ici. Vérifiez que votre base de données est conforme à l’exécution d’une migration en ligne.

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

• Extensions de liste d'autorisation 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 vitesse de 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. Vous utilisez une série d’onglets aidée par un Assistant pour créer une migration vers cette cible de serveur flexible depuis différentes sources possibles. Par défaut, le Type de serveur source est défini sur Serveur unique Azure Database pour PostgreSQL, qui est celui qui nous intéresse dans ce scénario.

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 et sélectionnez les détails correspondants pour Abonnement, Groupe de ressources et Nom du serveur. Une fois les sélections effectuées, sélectionnez Accéder à l’Assistant de migration et suivez les instructions de la section Configuration.

   

4. Si vous choisissez de créer un nouveau serveur flexible, sélectionnez Créer nouveau, puis Accéder à l’Assistant de 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.

Programme d’installation

L’onglet Configuration apparaît en premier. Si vous ne l’avez pas encore fait, établissez une liste d'autorisations pour les extensions nécessaires, comme décrit dans Configurer votre serveur flexible Azure Database pour PostgreSQL, avant de lancer une migration.

Le nom de la migration est l’identificateur unique de chaque migration vers cette cible de serveur flexible. Ce champ n’accepte que des caractères alphanumériques et n’accepte aucun caractère spécial à l’exception du tiret bas (_) et du trait d’union (-). Le nom doit commencer par un caractère alphanumérique. Le nom d’un serveur cible doit également être unique, car deux migrations vers le même serveur flexible cible ne peuvent 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

Option de migration vous permet de réaliser 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 la migration.
• 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.

Mode de migration vous permet de choisir entre une migration en ligne et une migration hors ligne. Dans ce cas, il doit être défini sur En ligne.

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. La réplication peut également être configurée manuellement en sélectionnant l’élément Réplication, sous Paramètres dans le menu de ressources du serveur unique, et en définissant Prise en charge de la réplication Azure sur LOGIQUE. Les deux approches redémarrent le serveur unique source.

Sélectionnez le bouton Suivant : sélectionner le serveur de runtime.

Serveur d’exécution

Le serveur d’exécution de migration est une fonctionnalité spécialisée intégrée au service de migration dans Azure Database pour PostgreSQL, conçu pour agir en tant que serveur intermédiaire pendant la migration. Il s’agit d’une instance de serveur flexible Azure Database pour PostgreSQL distincte qui n’est pas le serveur cible, mais utilisé pour faciliter la migration des bases de données à partir d’un environnement source accessible uniquement via un réseau privé.

Pour plus d’informations sur le serveur d’exécution, visitez la page du Serveur d’exécution de migration.

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

Se connecter à la source

La section Source vous invite à fournir des informations sur le 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 Serveur unique, les zones Emplacement et Version PostgreSQL sont remplies automatiquement. Veillez à fournir les informations d’identification d’un rôle d’administrateur, car elles sont nécessaires pour que le service de migration migre correctement les bases de données.

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.

Sélectionner la cible de migration

La section Sélectionner la cible de migration affiche les métadonnées du serveur flexible cible, comme Abonnement, Groupe de ressources, Nom du serveur, Emplacement et Version PostgreSQL.

Choisissez les valeurs appropriées pour Méthode d’authentification et tous les champs associés à l’authentification. Vérifiez que l’identité fournie est celle de l’utilisateur administrateur sur le serveur cible. Après avoir rempli toutes les informations requises, 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 : sélectionner la ou les bases de données pour la migration pour sélectionner les bases de données à migrer.

Sélectionner une ou plusieurs 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. Les bases de données sélectionnées qui existent sur le serveur cible avec exactement les mêmes noms sont remplacées.

Sélectionnez le bouton Suivant : résumé 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 informations et sélectionnez le bouton Démarrer la validation et la migration.

Portail Monitorer la migration

Une fois la migration démarrée, une notification s’affiche pour indiquer que la création de la validation ou 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, Mode de migration, Type de migration, Serveur source, Type du 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 Actualiser pour actualiser l’état de la validation ou de la migration.

Vous pouvez également sélectionner le nom d’une migration particulière 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 analyser 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 informations suivantes :

• 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.
• Nom de la validation : nom de chaque règle de validation spécifique.
• État de la 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 (UTC) et Heure de fin (UTC) : 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

Lorsque le sous-état PerformingPreRequisiteSteps est terminé, la migration passe au sous-état Migration des données, lorsque le clonage ou la copie des bases de données ont 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 nombres de tables (copiées, mises en file d’attente, copie en cours et erreurs) ainsi que 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 actualiser la page pour vérifier la progression.

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

Pour les options de migration Migrer et Valider et migrer, l’achèvement de la migration en ligne nécessite que l’utilisateur effectue une étape supplémentaire, qui consiste à déclencher l’action de basculement. Après avoir effectué la copie ou 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 depuis le portail en sélectionnant la migration et en sélectionnant le bouton Basculement .

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 depuis l’écran des détails de la migration :

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 Commandes 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 envoyées vers la cible pour la base de données Commandes. À 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, et seulement après 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 évènement de basculement avec une latence non nulle, 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, alors toutes les données modifiées au cours des 15 dernières minutes sont appliquées à 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 soit à zéro ou une valeur proche de zéro avant de déclencher le basculement.

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

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 aux prérequis suivants, qui s’appliquent aux scénarios de migration hors ligne.

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 :

• Le serveur flexible Azure Database pour PostgreSQL doit être déployé et correctement configuré dans Azure avant de commencer le processus de 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.

• Lors de la migration entre les versions de PostgreSQL (majeures ou mineures), assurez-vous de la compatibilité entre votre base de données et votre application en recherchant dans les notes de publication de potentiels changements cassants.

Configuration du réseau

La configuration du réseau est cruciale pour que le service de migration fonctionne correctement. Vérifiez que le serveur PostgreSQL source peut communiquer avec le serveur Azure Database pour PostgreSQL cible. Les configurations réseau suivantes sont essentielles pour une migration réussie.

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

Activer les extensions

Pour garantir la réussite de la migration à l’aide du service de migration dans Azure Database pour PostgreSQL, il peut être nécessaire de vérifier les extensions de votre instance PostgreSQL source. Les extensions fournissent des fonctionnalités qui peuvent être requises pour votre application. Veillez à vérifier les extensions sur l’instance PostgreSQL source avant de lancer le processus de migration.

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

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

Remarque

Un redémarrage est nécessaire quand vous apportez des modifications au paramètre shared_preload_libraries.

Vérifier les paramètres du 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 le serveur flexible Azure Database pour PostgreSQL pour appliquer la nouvelle configuration.

Important

Modifiez le paramètre de serveur password_encryption sur votre serveur flexible de SCRAM-SHA-256 à MD5 avant de lancer la migration. Cela est essentiel pour que les informations d’identification existantes sur le serveur unique fonctionnent sur votre serveur flexible.

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

L’exécution de la commande précédente retourne 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

L’exécution de la commande précédente retourne la sortie suivante :

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	L’identificateur unique de chaque migration vers cette cible serveur flexible. Ce champ n’accepte que des caractères alphanumériques et n’accepte aucun caractère spécial à l’exception du tiret bas (_) et du trait d’union (-). Le nom doit commencer et se terminer par un caractère alphanumérique. Le nom d’un serveur cible doit également être unique, car deux migrations vers le même serveur flexible cible ne peuvent avoir le même nom.
migration-mode	Il s'agit d'un paramètre facultatif. Valeur par défaut : hors connexion. La migration hors ligne 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 "./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/<sourceServerResourceGroup>/providers/Microsoft.DBforPostgreSQL/servers/<sourceServer>",
		"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 serveur unique.
adminCredentials	Requis	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 spécifié lors de la création d’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 spécifié lors de la création d’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 ou 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.

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 : liste les tentatives de migration actives (en cours) actuelles 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 terminé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.

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.
ValidationFailed	La migration a échoué pendant la validation préalable à 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.
CompletingMigration	Finalisation du processus de migration.
Completed	La migration est terminée, qu’elle soit dans un état réussi ou non.
CancelingRequestedDBMigrations	Annulation de la migration.
ValidationInProgress	La validation est en cours.

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.

Pour éviter que la migration en ligne ne manque d’espace de stockage pour les journaux, assurez-vous que vous disposez de suffisamment d’espace de table à l’aide d’un disque managé approvisionné. Pour ce faire, désactivez le paramètre serveur azure.enable_temp_tablespaces_on_local_ssd sur le serveur flexible pendant la durée de la migration, et rétablissez-le dans son état d’origine après la migration.

Configurer la 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 ;

• Lors de la migration entre les versions de PostgreSQL (majeures ou mineures), assurez-vous de la compatibilité entre votre base de données et votre application en recherchant dans les notes de publication de potentiels changements cassants.

Important

Modifiez le paramètre de serveur password_encryption sur votre serveur flexible de SCRAM-SHA-256 à MD5 avant de lancer la migration. Cela est essentiel pour que les informations d’identification existantes sur le serveur unique fonctionnent sur votre serveur flexible.

Configurer le réseau

La configuration du réseau est cruciale pour que le service de migration fonctionne correctement. Vérifiez que le serveur PostgreSQL source peut communiquer avec le serveur Azure Database pour PostgreSQL cible. Les configurations réseau suivantes sont essentielles pour une migration réussie.

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

Activer les extensions

Pour garantir la réussite de la migration à l’aide du service de migration dans Azure Database pour PostgreSQL, il peut être nécessaire de vérifier les extensions de votre instance PostgreSQL source. Les extensions fournissent des fonctionnalités qui peuvent être requises pour votre application. Veillez à vérifier les extensions sur l’instance PostgreSQL source avant de lancer le processus de migration.

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

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

Remarque

Un redémarrage est nécessaire quand vous apportez des modifications au paramètre shared_preload_libraries.

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.

Remarque

Certaines limitations s’appliquent à la migration en ligne qui sont documentées ici. Vérifiez que votre base de données est conforme à l’exécution d’une migration en ligne.

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

L’exécution de la commande précédente retourne 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

L’exécution de la commande précédente retourne la sortie suivante :

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	L’identificateur unique de chaque migration vers cette cible serveur flexible. Ce champ n’accepte que des caractères alphanumériques et n’accepte aucun caractère spécial à l’exception du tiret bas (_) et du trait d’union (-). Le nom doit commencer et se terminer par un caractère alphanumérique. Le nom d’un serveur cible doit également être unique, car deux migrations vers le même serveur flexible cible ne peuvent avoir le même nom.
migration-mode	Il s'agit d'un paramètre facultatif. La valeur par défaut est Offline. Pour les migrations en ligne, vous devez passer Online.
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 "./migrationBody.json" --migration-mode online

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/<sourceServerResourceGroup>/providers/Microsoft.DBforPostgreSQL/servers/<sourceServer>",
    "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 serveur unique.
adminCredentials	Requis	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 spécifié lors de la création d’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 spécifié lors de la création d’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 ou 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

Pour le mode de migration en ligne, la réplication logique doit être activée 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, utilisez :

az postgres flexible-server migration create --subscription 11111111-1111-1111-1111-111111111111 --resource-group my-learning-rg --name myflexibleserver --migration-name migration1 --properties "./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 : liste les tentatives de migration actives (en cours) actuelles 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 terminé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

Analyser les migrations

La commande show permet de surveiller les migrations en cours et fournit 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 de la commande CLI pour surveiller la migration :

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.
ValidationFailed	La migration a échoué pendant la validation préalable à 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.
WaitingForCutoverTrigger	La tâche de migration de données s’est terminée et attend que l’utilisateur déclenche le basculement.
CompletingMigration	Finalisation du processus de migration.
Completed	La migration est terminée, qu’elle soit dans un état réussi ou non.
CancelingRequestedDBMigrations	Annulation de la migration.
ValidationInProgress	La validation est en cours.

Basculement des migrations

Dans les migrations en ligne, une fois la migration des données de base terminée, la tâche de migration passe au sous-état WaitingForCutoverTrigger. Dans cet état, 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, vérifiez que :

• Les écritures vers la source sont arrêtées : le paramètre latency est 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 annuler 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 :

Vérifier la migration une fois terminée

Après une migration réussie, vérifiez que vous pouvez vous connecter à votre serveur flexible à l’aide des mêmes informations d’identification que sur le serveur unique. Si vous rencontrez des erreurs d’authentification sur votre serveur flexible après la migration à partir d’un serveur unique, cela peut être dû au fait que la machine virtuelle du serveur flexible est conforme à FIPS ou qu’elle utilise un algorithme de chiffrement de mot de passe (SCRAM-SHA-256) autre que le chiffrement MD5 du serveur unique. Pour résoudre ce problème, effectuez les étapes suivantes :

1. Modifiez le paramètre de serveur password_encryption sur votre serveur flexible de SCRAM-SHA-256 à MD5.
2. Réinitialisez la migration de votre serveur unique vers le serveur flexible.
3. Si les problèmes d’authentification persistent, supprimez le serveur flexible existant et approvisionnez-en un nouveau. Répétez les étapes 1 et 2 pour résoudre le problème.

Cela doit résoudre les erreurs d’authentification.

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