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.
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 une migration réussie en utilisant le 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.
Dans l’instance cible d’Azure Database pour PostgreSQL – Serveur flexible, activez les extensions prises en charge qui sont 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.
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 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.
Le service de migration inclut une expérience simple basée sur un Assistant sur le Portail Azure. Voici comment procéder :
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.
Accédez à votre cible Azure Database pour PostgreSQL - Serveur flexible.
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.
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.
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.
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.
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.
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.
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. Assurez-vous de fournir les informations d’identification d’un rôle d'administrateur, car cela est nécessaire 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.
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 ;
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 une migration réussie en utilisant le 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.
Dans l’instance cible d’Azure Database pour PostgreSQL – Serveur flexible, activez les extensions prises en charge qui sont 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 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.
Le service de migration inclut une expérience simple basée sur un Assistant sur le Portail Azure. Voici comment procéder :
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.
Accédez à votre cible Azure Database pour PostgreSQL - Serveur flexible.
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.
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.
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.
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.
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.
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.
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. Assurez-vous de fournir les informations d’identification d’un rôle d'administrateur, car cela est nécessaire 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.