Tutoriel : Migration en ligne à partir d’AWS RDS PostgreSQL vers Azure Database pour PostgreSQL à l’aide du service de migration en préversion
Cet article explique comment migrer votre base de données PostgreSQL d’AWS RDS vers Azure Database pour PostgreSQL en ligne.
Le service de migration dans Azure Database pour PostgreSQL est un service complètement managé intégré au Portail Azure et à Azure CLI. Il est conçu pour simplifier votre parcours de migration vers un serveur Azure Database pour PostgreSQL.
- Prérequis
- Effectuer la migration
- Surveiller la migration
- Basculement
- Vérifier la migration une fois terminée
Prérequis
Pour terminer la migration, vous devez disposer des prérequis suivants :
Avant de commencer la migration avec le service de migration Azure Database pour PostgreSQL, il est important de vérifier que les prérequis suivants, spécialement conçus pour les scénarios de migration en ligne, sont satisfaits.
- Vérifier la version source
- Installer test_decoding – Configuration source
- Définir la configuration cible
- Activer la capture des changements de données en tant que source
- Définir la configuration réseau
- Activer les extensions
- Vérifier les paramètres de serveur
- Vérifier les utilisateurs et les rôles
Vérifier la version source
La version du serveur PostgreSQL source doit être 9.5 ou une version ultérieure.
Si la version PostgreSQL source est inférieure à 9.5, mettez-la à niveau vers la version 9.5 ou une version ultérieure avant de commencer la migration.
Installer test_decoding – Configuration source
- test_decoding reçoit WAL par le biais du mécanisme de décodage logique et le décode en représentations textuelles des opérations effectuées.
- Dans Amazon RDS pour PostgreSQL, le plug-in test_decoding est préinstallé et prêt pour la réplication logique. Cela vous permet de configurer facilement des emplacements de réplication logique et de diffuser en continu des modifications WAL, ce qui facilite les cas d’usage tels que la capture des changements de données (CDC) ou la réplication vers des systèmes externes.
- Pour plus d’informations sur le plug-in de réplication logique, consultez la documentation PostgreSQL
Définir la configuration cible
- Avant la migration, un serveur flexible Azure Database pour PostgreSQL doit être créé.
- La référence SKU approvisionnée pour le serveur flexible Azure Database pour PostgreSQL doit correspondre à la source.
- Pour créer une nouvelle instance d’Azure Database pour PostgreSQL, consultez l’article Créer une instance d’Azure Database pour PostgreSQL
Activer la capture des changements de données en tant que source
Le plug-in de décodage logique
test_decoding
capture les enregistrements modifiés de la source.Dans la source, l’instance PostgreSQL, modifiez les paramètres suivants en créant un groupe de paramètres :
- Définir
rds.logical_replication = 1
- Définissez
max_replication_slots
sur une valeur supérieure à un. La valeur doit être supérieure au nombre de bases de données sélectionnées pour la migration. - Définissez
max_wal_senders
sur une valeur supérieure à un. Elle doit être au moins identique àmax_replication_slots
, plus le nombre d’expéditeurs déjà utilisés sur votre instance. - Le paramètre
wal_sender_timeout
met fin aux connexions de réplication inactives plus longtemps que le nombre spécifié de millisecondes. La valeur par défaut pour une instance d’AWS RDS pour PostgreSQL est30000 milliseconds (30 seconds)
. Définissez la valeur sur 0 (zéro) pour désactiver le mécanisme d’expiration, ce qui constitue un paramètre valide pour la migration.
- Définir
Dans le serveur flexible cible, 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
azure.enable_temp_tablespaces_on_local_ssd
du serveur pendant la durée de la migration et rétablissez-le dans son état d’origine après la migration.
Définir la configuration réseau
La configuration du réseau est cruciale pour que le service de migration fonctionne correctement. Vérifiez que le serveur PostgreSQL source peut communiquer avec le serveur Azure Database pour PostgreSQL cible. Les configurations réseau suivantes sont essentielles pour une migration réussie.
Pour plus d’informations sur la configuration réseau, consultez le Guide réseau pour le service de migration.
Activer les extensions
Pour garantir une migration réussie avec le service de migration dans Azure Database pour PostgreSQL, vous allez peut-être devoir vérifier les extensions de votre instance PostgreSQL source. Les extensions fournissent des fonctionnalités supplémentaires qui peuvent être requises pour votre application. Assurez-vous de vérifier les extensions sur l’instance PostgreSQL source avant de lancer le processus de migration.
Activez les extensions prises en charge et identifiées dans l’instance PostgreSQL source sur le serveur flexible Azure Database pour PostgreSQL cible.
Pour plus d’informations sur les extensions, rendez-vous sur Extensions dans Azure Database pour PostgreSQL.
Remarque
Un redémarrage est nécessaire lorsqu’une modification a été apportée au paramètre shared_preload_libraries
.
Vérifier les paramètres de serveur
Ces paramètres ne sont pas automatiquement migrés vers l’environnement cible et doivent être configurés manuellement.
Faites correspondre les valeurs des paramètres du serveur de la base de données PostgreSQL source à Azure Database pour PostgreSQL en accédant à la section « Paramètres du serveur » dans le Portail Azure et en mettant à jour manuellement les valeurs en conséquence.
Enregistrez les modifications apportées aux paramètres et, si nécessaire, redémarrez Azure Database pour PostgreSQL pour appliquer la nouvelle configuration.
Vérifier les utilisateurs et les rôles
Lors de la migration vers Azure Database pour PostgreSQL, il est essentiel de traiter séparément la migration des utilisateurs et des rôles, car une intervention manuelle est nécessaire :
Migration manuelle des utilisateurs et des rôles : les utilisateurs et leurs rôles associés doivent être migrés manuellement vers Azure Database pour PostgreSQL. Pour faciliter ce processus, vous pouvez utiliser l’utilitaire
pg_dumpall
avec l’indicateur--globals-only
pour exporter des objets globaux tels que des rôles et des comptes d’utilisateur. Exécutez la commande suivante, en remplaçant<<username>>
par le nom d’utilisateur réel et<<filename>>
par le nom de fichier de sortie souhaité :pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
Restriction sur les rôles de superutilisateur : Azure Database pour PostgreSQL ne prend pas en charge les rôles de superutilisateur. Par conséquent, les privilèges de superutilisateur accordés aux utilisateurs doivent être supprimés avant la migration. Veillez à ajuster les autorisations et les rôles en conséquence.
En procédant ainsi, vous pouvez vous assurer que les comptes d’utilisateur et les rôles sont correctement migrés vers Azure Database pour PostgreSQL sans rencontrer de problèmes liés aux restrictions associés aux rôles de superutilisateur.
Désactiver les réplicas de haute disponibilité (fiabilité) et de lecture dans la cible
Il est essentiel de désactiver les réplicas de haute disponibilité (fiabilité) et de lecture dans l’environnement cible. Ces fonctionnalités doivent uniquement être activées une fois la migration terminée.
En procédant ainsi, vous pouvez garantir un processus de migration fluide sans les variables ajoutées introduites par les réplicas de haute disponibilité et de lecture. Une fois la migration terminée et la base de données stable, vous pouvez activer ces fonctionnalités pour améliorer la disponibilité et la scalabilité de votre environnement de base de données dans Azure.
Effectuer la migration
Vous pouvez migrer à l’aide du Portail Azure ou d’Azure CLI.
Le Portail Azure offre une expérience simple et intuitive basée sur un Assistant qui vous guide tout au long de la migration. En suivant les étapes décrites dans ce tutoriel, vous pouvez transférer en toute transparence votre base de données vers un serveur flexible Azure Database pour PostgreSQL et tirer parti de sa scalabilité et de ses puissantes fonctionnalités.
Pour migrer avec le Portail Azure, vous configurez d’abord la tâche de migration, vous connectez à la source et à la cible, puis effectuez la migration.
Configurer la tâche de migration
Le service de migration inclut une expérience simple basée sur un Assistant sur le Portail Azure. Voici comment procéder :
Ouvrez votre navigateur web et accédez au portail. Entrez vos informations d’identification pour vous connecter. Il s’ouvre par défaut sur le tableau de bord des services.
Accédez à votre cible Azure Database pour PostgreSQL - Serveur flexible.
Dans le menu de gauche de l’onglet Vue d’ensemble du serveur flexible, faites défiler vers le bas jusqu’à Migration et sélectionnez cette option.
Cliquez sur le bouton Créer pour effectuer une migration à partir d’AWS RDS vers un serveur flexible Azure Database pour PostgreSQL. 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 cible Azure Database pour PostgreSQL, la grille contient des informations sur les tentatives de migration.
Cliquez sur le bouton **Créer **. Ensuite, vous passez par une série d’onglets basés sur un Assistant pour créer une migration vers cette cible Azure Database pour PostgreSQL à partir de l’instance PostgreSQL source.
Programme d’installation
Le premier onglet est l’onglet Configuration, où l’utilisateur doit fournir des détails de migration tels que le type de source du nom de migration pour lancer les migrations.
Le nom de la migration est l’identificateur unique de chaque migration vers cette cible de serveur flexible. Ce champ accepte uniquement les caractères alphanumériques et n’accepte aucun caractère spécial à l’exception du trait d’union (-). Le nom ne peut pas commencer par un trait d’union et doit être unique pour un serveur cible. Deux migrations vers la même cible de serveur flexible ne peuvent pas avoir le même nom.
Type de serveur source : en fonction de votre PostgreSQL source, vous pouvez sélectionner AWS RDS pour PostgreSQL ou Azure Database pour PostgreSQL – serveur unique, local ou machine virtuelle Azure.
L’option de migration vous permet d’effectuer des validations avant de déclencher une migration. Vous pouvez choisir l’une des options suivantes :
- Valider : vérifie la préparation de votre serveur et de votre base de données pour la migration vers la cible.
- Migrer : ignore les validations et démarre les migrations.
- Valider et migrer : effectue la validation avant de déclencher une migration. La migration est uniquement déclenchée s’il n’y a pas d’échecs de validation.
Il est toujours recommandé de choisir l’option Valider ou Valider et migrer pour effectuer des validations de prémigration avant d’exécuter la migration. Pour en savoir plus sur la validation de la prémigration, reportez-vous à cette documentation.
- Mode de migration vous permet de choisir le mode de la migration. Hors connexion est l’option par défaut.
Cliquez sur le bouton Suivant : Se connecter à la source.
Sélectionner un serveur d’exécution
Le serveur d’exécution de migration est une fonctionnalité spécialisée intégrée au service de migration, conçu pour agir en tant que serveur intermédiaire pendant la migration. Il s’agit d’une instance de serveur flexible Azure Database pour PostgreSQL distincte qui n’est pas le serveur cible, mais qui est utilisée pour faciliter la migration des bases de données à partir d’un environnement source accessible uniquement via un réseau privé.
Pour plus d’informations sur le serveur d’exécution, consultez Serveur d’exécution de migration.
Se connecter à la source
L’onglet Se connecter à la source vous invite à fournir des informations relatives à la source sélectionnée dans l’onglet Configuration, qui est la source des bases de données.
- Nom du serveur : indiquez le nom d’hôte ou l’adresse IP de l’instance PostgreSQL source
- Port : numéro de port du serveur source
- Nom de connexion de l’administrateur du serveur : nom d’utilisateur du serveur PostgreSQL source
- Mot de passe : mot de passe du serveur PostgreSQL source
- Mode SSL : les valeurs prises en charge sont préféré et requis. Lorsque le protocole SSL sur le serveur PostgreSQL source est DÉSACTIVÉ, utilisez SSLMODE=prefer. Si le protocole SSL sur le serveur source est ACTIVÉ, utilisez SSLMODE=require. Les valeurs SSL peuvent être déterminées dans le fichier Postgresql.conf.
- Tester la connexion : effectue le test de connectivité entre la cible et la source. Une fois la connexion établie, les utilisateurs peuvent passer à l’étape suivante. Sinon, nous devons identifier les problèmes de mise en réseau entre la cible et la source et vérifier le nom d’utilisateur et le mot de passe de la source. L’établissement d’une connexion de test prend quelques minutes.
Une fois le test de connexion réussi, sélectionnez Suivant : Sélectionner la cible de migration
Sélectionner la cible de migration
L’onglet Sélectionner la cible de migration affiche les métadonnées du serveur flexible cible telles que le nom de l’abonnement, le groupe de ressources, le nom du serveur, l’emplacement et la version PostgreSQL.
- Nom d’utilisateur administrateur : nom d’utilisateur administrateur du serveur PostgreSQL cible
- Mot de passe : mot de passe du serveur PostgreSQL cible
- Tester la connexion : effectue le test de connectivité entre la cible et la source. Une fois la connexion établie, les utilisateurs peuvent passer à l’étape suivante. Sinon, nous devons identifier les problèmes de mise en réseau entre la cible et la source et vérifier le nom d’utilisateur et le mot de passe de la cible. Il faut quelques minutes pour que la connexion de test établisse une connexion la cible et la source.
Une fois le test de connexion réussi, sélectionnez le bouton Suivant : Sélectionner la ou les bases de données à migrer.
Sélectionner des bases de données pour la migration
Sous cet onglet, une liste de bases de données utilisateur se trouve à l’intérieur du serveur source sélectionné dans l’onglet de configuration. 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.
Après avoir sélectionné les bases de données, sélectionnez Suivant : Résumé
Résumé
L’onglet Résumé récapitule toutes les informations de la source et de la cible pour la création de la validation ou de la migration. Passez en revue les détails et cliquez sur le bouton Démarrer.
Surveiller la migration
Une fois que vous avez cliqué sur le bouton Démarrer, une notification s’affiche quelques secondes plus tard pour indiquer que la création de la validation ou de la migration est réussie. Vous êtes ensuite redirigé automatiquement vers la page Migration du serveur flexible, qui a 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 de serveur source, Bases de données, Durée et Heure de début. Les entrées sont affichées dans l’ordre décroissant de l’heure de début avec l’entrée la plus récente en haut. Vous pouvez utiliser le bouton d’actualisation pour actualiser l’état de la validation ou de la migration. Sélectionnez le nom de la migration dans la grille pour afficher les informations associées.
Une fois la validation ou la migration créée, l’état passe à InProgress avec le sous-état PerformingPreRequisiteSteps. Le workflow prend 2 à 3 minutes pour configurer l’infrastructure de migration et les connexions réseau.
Détails de la migration
Dans l’onglet Configuration, nous avons défini l’option de migration sur Migrer et valider. Dans ce scénario, les validations sont effectuées en premier avant le début 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 se termine sans erreur, la migration démarre et le flux de travail passe au sous-état Migration des données.
Vous pouvez voir les résultats de la validation et de la migration au niveau de l’instance et de la base de données.
Les états de migration possibles incluent :
États de migration
State | Description |
---|---|
InProgress | L’infrastructure de migration est en cours de configuration, ou la migration des données est en cours. |
Annulé | La migration est annulée ou supprimée. |
Échec | La migration a échoué. |
Échec de la validation | La validation a échoué. |
Réussi | La migration a réussi et est terminée. |
WaitingForUserAction | Applicable uniquement pour la migration en ligne. Attente d’une action de l’utilisateur pour effectuer le basculement. |
Sous-états de la migration
Sous-état | Description |
---|---|
PerformingPreRequisiteSteps | L’infrastructure est en cours de configuration pour la migration des données. |
Validation en cours | La validation est en cours. |
MigratingData | La migration des données est en cours. |
CompletingMigration | La migration est en phase finale. |
Terminé | La migration est terminée. |
Échec | La migration a échoué. |
Sous-états de validation
Sous-état | Description |
---|---|
Échec | La validation a échoué. |
Réussi | La validation a réussi. |
Avertissement | La validation présente un avertissement. |
Basculement
Si les deux options Migrer et Valider et migrer sont présentes, l’exécution de la migration en ligne nécessite une autre étape de la part de l’utilisateur : une action de basculement. Après la copie/le clonage des données de base, la migration passe à l’état WaitingForUserAction
et au sous-état `WaitingForCutoverTrigger'. Dans cet état, l’utilisateur peut déclencher le basculement à partir du portail en sélectionnant la migration.
Avant de lancer le basculement, il est important de s’assurer que :
Les écritures vers la source sont arrêtées : la valeur de
Latency
est 0 ou proche de 0. Les informationsLatency
peuvent être obtenues à partir de l’écran des détails de la migration, comme indiqué ci-dessous :La valeur de
latency
diminue à 0 ou proche de 0La valeur de
latency
indique quand la cible a été synchronisée pour la dernière fois avec la source. À ce stade, les écritures vers 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 queLatency
puisse atteindre une valeur proche de 0, puis de lancer le basculement. L’opération de basculement applique toutes les modifications en attente de la source vers la cible, et termine la migration. Si vous déclenchez un « basculement » avec un paramètreLatency,
différent de zéro, la réplication s’arrête jusqu’à ce point dans le temps. Toutes les données se trouvent sur la source jusqu’à ce que le point de basculement soit appliqué à la cible. Si, par exemple, la latence est de 15 minutes au point de basculement, toutes données modifiées durant les 15 dernières minutes sont appliquées à la cible. Le temps nécessaire dépend du backlog des changements survenus au cours des 15 dernières minutes. Par conséquent, nous vous recommandons d’attendre que la latence atteigne zéro ou une valeur proche de zéro avant de déclencher le basculement.La migration passe à l’état
Succeeded
dès que le sous-étatMigrating Data
ou le basculement (dans la migration en ligne) s’est correctement terminé. S’il y a un problème au niveau du sous-étatMigrating Data
, la migration passe à l’étatFailed
.
Vérifier la migration une fois terminée
Une fois les bases de données terminées, vous devez valider manuellement les données entre la source et la cible et vérifier que tous les objets de la base de données cible sont bien créés.
Après la migration, vous pouvez effectuer les tâches suivantes :
- Vérifiez les données sur votre serveur flexible et vérifiez qu’il s’agit d’une copie exacte de l’instance source.
- Après vérification, et si cela est nécessaire, activez l’option haute disponibilité sur votre serveur flexible.
- Changez la référence SKU du serveur flexible en fonction des besoins d’applications. Cette modification nécessite un redémarrage du serveur de base de données.
- Si vous modifiez les valeurs par défaut de certains paramètres de serveur sur l’instance source, copiez les valeurs de ces paramètres de serveur dans le serveur flexible.
- Copiez d’autres paramètres de serveur, tels que les étiquettes, les alertes et les règles de pare-feu (le cas échéant), de l’instance source vers le serveur flexible.
- Apportez des modifications à votre application pour lui faire pointer les chaînes de connexion vers un serveur flexible.
- Surveillez de près le niveau de performance des bases de données pour déterminer s’il est nécessaire de l’ajuster.