Partager via

Meilleures pratiques pour une migration fluide vers Azure Database pour PostgreSQL

  • Article

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 dans la page 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 en savoir plus, consultez Validations de prémigration.

Configuration du serveur flexible cible

Durant 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 log). 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.

Si vous souhaitez calculer le nombre, connectez-vous à l’instance source, puis exécutez cette commande pour toutes les bases de données à migrer :

SELECT pg_size_pretty( pg_database_size('dbname') );

Nous vous recommandons d’allouer suffisamment d’espace de stockage sur le serveur flexible, ce qui équivaut à 1,25 fois ou 25 % d’espace de stockage en plus, par rapport à ce qui est utilisé selon la sortie de la commande précédente. Vous pouvez également utiliser la fonctionnalité de croissance automatique du stockage.

Important

La taille de stockage peut être réduite pendant la configuration manuelle ou la croissance automatique du stockage. Chaque étape du spectre de configuration du stockage double de taille. Il est donc prudent d’estimer l’espace de stockage nécessaire au préalable.

Le guide de démarrage rapide permettant de créer une instance d’Azure Database pour PostgreSQL - Serveur flexible à l’aide du portail est un excellent point de départ. Pour plus d’informations sur chaque configuration de serveur, consultez Options de calcul et de stockage dans Azure Database pour PostgreSQL - Serveur flexible.

Chronologie de migration

Une fois démarrée, chaque migration a une durée de vie maximale de sept jours (168 heures), et expire au-delà. Pour éviter l’expiration de la migration, exécutez la migration et le basculement d’application une fois que la validation des données et toutes les vérifications ont été effectuées. Dans les migrations en ligne, une fois la copie de base initiale terminée, la fenêtre de basculement dure trois jours (72 heures) avant d’expirer. Dans les migrations hors connexion, les applications doivent cesser d’écrire dans la base de données pour éviter toute perte de données. De même, pour une migration en ligne, maintenez le trafic à un niveau faible tout au long de la migration.

La plupart des serveurs hors production (développement, UAT, test et préproduction) sont migrés à l’aide de migrations hors connexion. Dans la mesure où ces serveurs comportent moins de données que les serveurs de production, la migration est rapide. 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. En raison des nombreux facteurs qui peuvent affecter le temps de migration, il est difficile d’estimer la durée totale de la migration. La meilleure approche consiste à effectuer un test de migration avec votre charge de travail.

Les phases suivantes sont prises en compte dans le calcul du temps d’arrêt total pour effectuer la migration du serveur de production :

  • Migration basée sur une restauration à un instant dans le passé : le meilleur moyen d’obtenir une estimation correcte du temps nécessaire à la migration de votre serveur de base de données de production consiste à restaurer votre serveur de production à un instant dans le passé, et à exécuter la migration hors connexion sur ce serveur nouvellement restauré.

  • Migration de la mémoire tampon : une fois l’étape précédente effectuée, vous pouvez planifier la migration en 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 significative, effectuez un autre test en appliquant au serveur la méthode de restauration à un instant dans le passé. Toutefois, pour la plupart des serveurs, l’augmentation de taille ne devrait pas être très significative.

  • Validation des données : une fois la migration du serveur de production terminée, vous devez vérifier si les données du serveur flexible sont une copie exacte de l’instance source. Vous pouvez utiliser des outils open source ou tiers, ou effectuer la validation manuellement. Préparez les étapes de validation à 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 pour tous les objets de base de données (tables, séquences, extensions, procédures et index).

    • Comparaison des ID maximal ou minimal des colonnes clés liées à l’application.

      Remarque

      La taille comparative des bases de données n’est pas la métrique appropriée pour la validation. L’instance source peut avoir des ballonnements ou des tuples morts, ce qui peut augmenter sa taille. Il est normal qu’il existe des différences de taille entre les instances sources et les serveurs cibles. Un problème au cours des trois étapes précédentes de la validation indique un problème de migration.

  • Migration des paramètres du serveur : les paramètres serveur personnalisés, les règles de pare-feu (le cas échéant), les balises et les alertes doivent être copiés manuellement 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 une validation réussie. 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

Bien qu’une migration se déroule souvent sans problème, il est recommandé de se préparer aux événements imprévus si vous avez besoin de plus de temps pour le débogage, ou si vous devez redémarrer une 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 à l’aide du service de migration. La migration a été effectuée à l’aide d’un serveur flexible ayant la 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

Les chiffres précédents vous donnent une idée approximative du temps nécessaire à 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 afin d’effectuer des migrations plus rapides. Azure Database pour PostgreSQL - Serveur flexible prend en charge la mise à l’échelle du calcul et des IOPS avec un temps d’arrêt quasi nul. Ainsi, 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.

Améliorer la vitesse de migration : migration parallèle des tables

Nous recommandons une référence SKU puissante pour la cible, car le service de migration PostgreSQL s’exécute à partir 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 distribution des données entre les tables doit être plus équilibrée, ou si une référence SKU plus puissante n’affecte pas de manière significative la vitesse de migration.

Si la distribution des données sur la source est fortement asymétrique, et si la plupart des données sont présentes dans une seule table, le calcul alloué pour la migration doit être entièrement utilisé, ce qui crée un goulot d’étranglement. Les tables volumineuses sont donc fractionnées en blocs plus petits, qui sont ensuite migrés en parallèle. Cette fonctionnalité s’applique aux tables de plus de 1 000 000 (1 million) de tuples. Le fractionnement de la table en blocs plus petits est possible si l’une des conditions suivantes est remplie :

  • La table doit avoir une colonne avec une clé primaire simple (non composite) ou un index unique de type int ou significant int.

    Remarque

    Dans le cas de la première ou de la deuxième approche, vous devez évaluer soigneusement les implications de l’ajout d’une colonne d’index unique au schéma source. Vous ne devez procéder aux changements qu’après avoir vérifié que l’ajout d’une colonne d’index unique n’affectera pas l’application.

  • Si la table n’a pas de clé primaire simple ou d’index unique de type int ou significant int, mais qu’elle comporte une colonne qui répond aux critères de type de données, la colonne peut être convertie en index unique à l’aide de la commande suivante. 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 ou d’index unique simple int/big int, ou de colonne répondant aux critères de type de données, vous pouvez ajouter une colonne de ce type en utilisant 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 précédentes est remplie, la table est migrée dans plusieurs partitions en parallèle, ce qui doit permettre une accélération de la vitesse de migration.

Fonctionnement

  • Le service de migration recherche les valeurs entières maximale et minimale de la clé primaire/de l’index unique de la table, qui doivent être fractionnées et migrées en parallèle.
  • Si la différence entre la valeur minimale et la valeur maximale est supérieure à 1 000 000 (1 million), la table est fractionné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 1 000 000 (1 million) de lignes. La différence entre les valeurs minimale et maximale de la clé primaire est donc supérieure à 1 000 000 (1 million).
  • 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 permet de résoudre les problèmes tels que les lignes mortes et le ballonnement des tables pour garantir une utilisation efficace de l’espace de stockage. Cela permet également d’accélérer la migration, car le temps de migration est fonction de la taille de la base de données.

PostgreSQL fournit la commande VACUUM pour récupérer l’espace de stockage occupé par les lignes mortes. L’option ANALYZE collecte également des statistiques pour optimiser davantage la planification des requêtes. Pour les tables ayant une activité d’écriture intensive, le processus VACUUM peut être plus agressif avec l’utilisation de VACUUM FULL, mais son exécution nécessite plus de temps.

  • 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 FULL récupère efficacement l’espace, alors 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 des objets volumineux, par exemple 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 font généralement référence à des circonstances, des configurations ou des prérequis uniques que vous devez prendre en compte avant de poursuivre un tutoriel ou un module. Ces conditions peuvent inclure des versions logicielles spécifiques, des configurations matérielles requises ou d’autres outils nécessaires au suivi du contenu d’apprentissage.

Migration en ligne

La migration en ligne utilise pgcopydb follow, et certaines restrictions de décodage logique s’appliquent. Nous vous recommandons également de disposer d’une clé primaire dans toutes les tables d’une base de données en cours de migration en ligne. En l’absence de clé primaire, seules les opérations insert sont prises en compte durant 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.

Remarque

Dans le cas de la migration en ligne de tables sans clé primaire, seules les opérations insert sont réexécutées sur la cible. Cela peut introduire une incohérence dans la base de données si les enregistrements mis à jour ou supprimés dans la source ne se reflètent pas sur la cible.

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

  1. Supprimez temporairement (dissociez) le wrapper de données étrangères sur l’instance source.
  2. Effectuez la migration des données restantes à l’aide du service de migration.
  3. Restaurez les rôles, l’utilisateur et les liens du wrapper de données étrangères vers la cible après la migration.

Base de données avec extension postGIS

L’extension postGIS comporte des changements cassants/des problèmes de compatibilité entre les différentes versions. Si vous migrez vers un serveur flexible, l’application doit être vérifiée par rapport à la dernière version de postGIS. Ainsi, vous aurez la certitude que l’application ne sera pas impactée, ou que seuls les changements nécessaires seront apporté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

Parfois, 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 scénario, vous pouvez octroyer à migration user l’autorisation de fermer toutes les connexions actives à la base de données, ou de fermer les connexions manuellement avant de réessayer la migration.

Contenu connexe