Meilleures pratiques pour une migration fluide vers Azure Database pour PostgreSQL
S’APPLIQUE À :
Azure Database pour PostgreSQL – Serveur flexible
Cet article décrit les pièges courants, et les bonnes pratiques pour garantir une migration fluide et réussie vers Azure Database pour PostgreSQL.
Validation de la prémigration
Comme première étape de la migration, exécutez la validation de prémigration avant d’effectuer une migration. Vous pouvez utiliser les options Valider et Valider et migrer de la page de configuration de la migration. La validation de prémigration effectue des vérifications approfondies par rapport à un ensemble de règles prédéfini. L’objectif est d’identifier les problèmes potentiels et de fournir des insights exploitables pour les actions correctives. Continuez à exécuter la validation de prémigration jusqu’à obtenir l’état Réussi. Pour plus d’informations, sélectionnez Validations de prémigration.
Configuration du serveur flexible cible
Pendant la copie de base initiale des données, plusieurs instructions d’insertion sont exécutées sur la cible, ce qui génère des journaux WAL (Write Ahead Logs). Tant qu’ils ne sont pas archivés, ces journaux WAL consomment du stockage sur la cible en plus du stockage nécessaire pour la base de données.
Pour calculer le chiffre, connectez-vous à l’instance source et exécutez cette commande pour migrer toutes les bases de données :
SELECT pg_size_pretty( pg_database_size('dbname') );
Nous vous conseillons d’allouer suffisamment de stockage sur le serveur flexible, à savoir l’équivalent de 1,25 fois ou 25 % de stockage en plus par rapport au chiffre donné par la sortie de la commande ci-dessus. La fonction de croissance automatique du stockage peut également être utilisée.
Important
La taille de stockage peut être réduite pendant la configuration manuelle ou la croissance automatique du stockage. Comme chaque étape du spectre de configuration du stockage double la taille, nous vous conseillons d’estimer le stockage nécessaire au préalable.
Le guide de démarrage rapide Créer un serveur flexible Azure Database pour PostgreSQL en utilisant le portail est un excellent point de départ. L’article Options de calcul et de stockage dans Azure Database pour PostgreSQL - Serveur flexible fournit également des informations détaillées sur chaque configuration de serveur.
Chronologie de migration
Une fois démarrée, chaque migration a une durée de vie maximale de sept jours (168 heures), au bout desquels elle expire. Vous pouvez effectuer la migration et le basculement d’application une fois terminées la validation des données et toutes les vérifications pour éviter l’expiration de la migration. Dans les migrations en ligne, une fois la copie de base initiale effectuée, la fenêtre de basculement a une durée de vie de trois jours (72 heures) avant expiration. Dans les migrations hors connexion, les applications doivent cesser d’écrire dans la base de données pour éviter la perte de données. De même, pour la migration en ligne, maintenez le trafic faible tout au long de la migration.
La plupart des serveurs hors production (développement, UAT, test, mise en lot) sont migrés en mode hors connexion. Sachant que ces serveurs comportent moins de données que les serveurs de production, la migration aboutit rapidement. Pour la migration d’un serveur de production, vous devez connaître le temps que va prendre la migration afin de vous organiser à l’avance.
Le temps nécessaire à une migration dépend de plusieurs facteurs. Il varie selon le nombre de bases de données, leur taille, le nombre de tables dans chaque base de données, le nombre d’index et la répartition des données entre les tables. Il dépend également de la référence SKU du serveur cible ainsi que des IOPS disponibles sur l’instance source et le serveur cible. Compte tenu des nombreux facteurs qui peuvent influer sur le temps de migration, il est difficile d’estimer le temps total de la migration. La meilleure approche est d’effectuer une migration de test avec votre charge de travail.
Les phases suivantes permettent de calculer le temps d’arrêt total lié à la migration du serveur de production.
Migration de la restauration à un instant dans le passé – Le meilleur moyen d’obtenir une estimation correcte du temps que va prendre la migration de votre serveur de base de données de production est de restaurer votre serveur de production à un instant dans le passé et d’exécuter la migration hors connexion sur ce serveur nouvellement restauré.
Migration de la mémoire tampon – Après avoir effectué l’étape précédente, vous pouvez prévoir d’effectuer la migration de production effective à une période où le trafic de l’application est faible. Cette migration peut être prévue le jour même ou plus probablement une semaine plus tard. Entre temps, la taille du serveur source peut avoir augmenté. Mettez à jour le temps de migration estimé pour votre serveur de production en fonction de l’ampleur de cette augmentation. Si l’augmentation est sensible, vous pouvez envisager d’effectuer un autre test en utilisant le serveur restauré à un instant dans le passé. Mais pour la plupart des serveurs, l’augmentation de la taille ne devrait pas être suffisamment importante.
Validation des données : une fois que la migration du serveur de production est terminée, vous devez vérifier que les données du serveur flexible sont la copie exacte de l’instance source. Les clients peuvent utiliser des outils open source/tiers ou faire une validation manuelle. Préparez les étapes de validation que vous voulez effectuer avant la migration réelle. La validation peut porter sur les points suivants :
Correspondance du nombre de lignes pour toutes les tables impliquées dans la migration.
Nombres correspondants de tous les objets de base de données (tables, séquences, extensions, procédures, index)
Comparaison des valeurs maximales ou minimales des ID des colonnes clés liées à l’application
Remarque
La taille des bases de données doit être la bonne métrique pour la validation. L’instance source peut avoir des ballonnements/tuples morts, ce qui peut augmenter la taille de l’instance source. Il est tout à fait normal d’avoir des différences de taille entre les instances sources et les serveurs cibles. Si vous rencontrez une difficulté dans les trois premières étapes de validation, c’est qu’il y a un problème au niveau de la migration.
Migration des paramètres du serveur : les paramètres de serveur personnalisés, les règles de pare-feu (le cas échéant), les étiquettes et les alertes doivent être copiés manuellement à partir de l’instance source vers la cible.
Changement des chaînes de connexion : l’application doit changer ses chaînes de connexion au serveur flexible après la validation. Cette activité est coordonnée avec l’équipe des applications pour changer toutes les références de chaînes de connexion pointant vers l’instance source. Dans le serveur flexible, le paramètre utilisateur peut être utilisé au format user=username dans la chaîne de connexion.
Par exemple : psql -h myflexserver.postgres.database.azure.com -u user1 -d db1
Même si la migration se déroule souvent sans problème, une bonne pratique est de se préparer à des événements imprévus qui pourraient nécessiter des opérations de débogage ou un redémarrage de la migration.
Évaluation de la vitesse de migration
Le tableau suivant indique le temps nécessaire pour effectuer des migrations de bases de données de diverses tailles en utilisant le service de migration. La migration a été effectuée avec un serveur flexible de référence SKU Standard_D4ds_v4 (4 cœurs, 16 Go de mémoire, 128 Go de disque et 500 IOPS)
| Taille de la base de données | Temps approximatif pris (HH:MM) |
|---|---|
| 1 Go | 00:01 |
| 5 Go | 00:03 |
| 10 Go | 00:08 |
| 50 Go | 00:35 |
| 100 Go | 01:00 |
| 500 Go | 04:00 |
| 1 000 Go | 07:00 |
Notes
Les chiffres ci-dessus vous donnent une idée approximative du temps nécessaire pour mener à bien la migration. Nous vous recommandons vivement d’exécuter une migration de test avec votre charge de travail afin d’obtenir une valeur précise pour la migration de votre serveur.
Important
Choisissez une référence SKU supérieure pour votre serveur flexible si vous voulez une migration plus rapide. Comme le serveur flexible Azure Database pour PostgreSQL prend en charge la mise à l’échelle des IOPS et du calcul avec un temps d’arrêt quasi nul, la référence SKU peut être mise à jour avec un temps d’arrêt minimal. Vous pouvez toujours changer de référence SKU en fonction des besoins de l’application après la migration.
Accélérer la migration – Migration parallèle de tables
Une référence SKU puissante est recommandée pour la cible, car le service de migration PostgreSQL s’exécute en dehors d’un conteneur sur le serveur flexible. Une référence SKU puissante permet de migrer davantage de tables en parallèle. Vous pouvez mettre à l’échelle le SKU vers votre configuration préférée après la migration. Cette section contient des étapes permettant d’améliorer la vitesse de migration si la répartition des données entre les tables est inégale et/ou si une référence SKU plus puissante n’impacte pas la vitesse de migration de manière significative.
Si la répartition des données sur la source est très asymétrique, la plupart des données se trouvent dans une seule table. Dans ce cas, le calcul alloué pour la migration doit être entièrement utilisé et cela crée un goulot d’étranglement. Par conséquent, les grandes tables sont divisées en petits blocs qui sont ensuite migrés en parallèle. Cette fonctionnalité s’applique aux tables avec plus de 10000000 (10 m) tuples. Il est possible de fractionner la table en blocs plus petits si l’une des conditions suivantes est remplie.
La table doit avoir une colonne avec une clé primaire simple (non composée), ou un index unique de type int ou int significatif.
Remarque
Dans le cas de l’approche 2 ou 3, l’utilisateur doit évaluer soigneusement les implications de l’ajout d’une colonne d’index unique au schéma source. Ce n’est qu’après confirmation que l’ajout d’une colonne d’index unique n’affectera pas l’application si l’utilisateur décide de poursuivre avec les modifications.
Si la table n’a pas de clé primaire simple ou d’index unique de type int ou int significatif, mais a une colonne qui répond aux critères de type de données, la colonne peut être convertie en index unique avec la commande ci-dessous. Cette commande ne nécessite pas de verrou sur la table.
create unique index concurrently partkey_idx on <table name> (column name);Si la table n’a pas de clé primaire int/big int simple, d’index unique ou de colonne qui répond aux critères de type de données, vous pouvez ajouter une telle colonne à l’aide de ALTER et la supprimer après la migration. L’exécution de la commande ALTER nécessite un verrou sur la table.
alter table <table name> add column <column name> big serial unique;
Si l’une des conditions ci-dessus est remplie, la table est migrée en plusieurs partitions en parallèle, ce qui devrait significativement accélérer la migration.
Fonctionnement
- Le service de migration recherche la valeur entière maximale et minimale de la clé primaire/l’index unique de la table qui doit être fractionnée et migrée en parallèle.
- Si la différence entre la valeur minimale et la valeur maximale est supérieure à 10000000 (10 m), la table est divisée en plusieurs parties et chaque partie est migrée en parallèle.
En résumé, le service de migration PostgreSQL migre une table dans des threads parallèles et réduit le temps de migration dans les cas suivants :
- La table a une colonne avec une clé primaire simple, ou un index unique de type int ou int significatif.
- La table comporte au moins 10 000 000 (10 m) lignes, de sorte que la différence entre la valeur minimale et la valeur maximale de la clé primaire est supérieure à 10 000 000 (10m).
- La référence SKU utilisée a des cœurs inactifs qui peuvent être exploités pour la migration de la table en parallèle.
Nettoyer le ballonnement dans la base de données PostgreSQL
Au fil du temps, quand les données sont ajoutées, mises à jour et supprimées, PostgreSQL est susceptible d’accumuler des lignes mortes et de l’espace de stockage perdu. Ce ballonnement peut entraîner une augmentation des besoins de stockage et une diminution des performances des requêtes. Le nettoyage est une tâche de maintenance essentielle qui permet de récupérer cet espace perdu et qui garantit le fonctionnement efficace de la base de données. Le nettoyage résout les problèmes tels que les lignes mortes et le ballonnement de table, ce qui garantit une utilisation efficace du stockage. En particulier, il permet de garantir une migration plus rapide, car le temps de migration varie en fonction de la taille de la base de données.
PostgreSQL fournit la commande VACUUM pour récupérer le stockage occupé par les lignes mortes. Par ailleurs, l’option ANALYZE collecte des statistiques pour optimiser davantage la planification des requêtes. Pour les tables qui ont une forte activité d’écriture, le processus VACUUM peut être plus agressif en utilisant VACUUM FULL, mais son exécution est plus longue.
- Nettoyage standard
VACUUM your_table;
- Nettoyage avec analyse
VACUUM ANALYZE your_table;
- Nettoyage agressif pour les tables avec écriture intensive
VACUUM FULL your_table;
Dans cet exemple, remplacez your_table par le nom de la table réelle. La commande VACUUM sans paramètre FULL récupère l’espace de manière efficace, tandis que VACUUM ANALYZE optimise la planification des requêtes. L’option VACUUM FULL doit être utilisée judicieusement en raison de son impact plus important sur les performances.
Certaines bases de données stockent de grands objets, comme des images ou des documents, qui peuvent contribuer au ballonnement de la base de données au fil du temps. La commande VACUUMLO est conçue pour les objets volumineux dans PostgreSQL.
- Nettoyage des objets volumineux
VACUUMLO;
L’incorporation régulière de ces stratégies de nettoyage garantit la bonne gestion de la base de données PostgreSQL.
Points particuliers à prendre en compte
Il existe des conditions particulières qui référencent généralement des circonstances, des configurations ou des prérequis uniques dont les étudiants doivent prendre connaissance avant de suivre un tutoriel ou un module. Ces conditions peuvent être des versions logicielles, des exigences matérielles ou des outils supplémentaires spécifiques nécessaires pour mettre en pratique le contenu d’apprentissage.
Migration en ligne
La migration en ligne utilise suivre pgcopydb et certaines restrictions de décodage logique s’appliquent. En outre, il est recommandé d’avoir une clé primaire dans toutes les tables d’une base de données faisant l’objet d’une migration en ligne. Si la clé primaire est absente, seules les opérations d’insertion peuvent être reflétées pendant la migration, à l’exclusion des mises à jour ou des suppressions. Ajoutez une clé primaire temporaire aux tables appropriées avant de poursuivre la migration en ligne.
Une alternative consiste à utiliser la commande ALTER TABLE où l’action est REPLICA IDENTIY avec l’option FULL. L’option FULL enregistre les anciennes valeurs de toutes les colonnes de la ligne afin que, même en l’absence d’une clé primaire, toutes les opérations CRUD soient reflétées sur la cible pendant la migration en ligne. Si aucune de ces options ne fonctionne, effectuez plutôt une migration hors connexion.
Base de données avec extension postgres_fdw
Le module postgres_fdw fournit le wrapper de données étrangères postgres_fdw, qui peut être utilisé pour accéder aux données stockées dans des serveurs PostgreSQL externes. Si votre base de données utilise cette extension, vous devez effectuer les étapes suivantes pour garantir la réussite de la migration.
- Supprimez (dissociez) temporairement le wrapper de données externes sur l’instance source.
- Effectuez la migration des données restantes avec le service de migration.
- Restaurez les rôles du wrapper de données externes, les utilisateurs et les liaisons sur la cible une fois la migration terminée.
Base de données avec extension postGIS
L’extension Postgis a des changements cassants/problèmes de compatibilité entre les différentes versions. Si vous migrez vers un serveur flexible, l’application doit être vérifiée sur la dernière version postGIS pour qu’elle ne soit pas impactée ou pour que les changements nécessaires soient effectués. Les actualités postGIS et les notes de publication constituent un bon point de départ pour comprendre les changements cassants entre les versions.
Nettoyage de la connexion de base de données
Vous pouvez rencontrer cette erreur quand vous démarrez une migration :
CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.
Dans ce cas, vous pouvez accorder à migration user l’autorisation de fermer toutes les connexions actives à la base de données ou de fermer manuellement les connexions avant de réessayer la migration.
Contenu connexe
Commentaires
Prochainement : Tout au long de l'année 2024, nous supprimerons progressivement les GitHub Issues en tant que mécanisme de retour d'information pour le contenu et nous les remplacerons par un nouveau système de retour d'information. Pour plus d’informations, voir: https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour