Meilleures pratiques pour pg_dump et pg_restore pour Azure Database pour PostgreSQL - Serveur flexible

2025-06-21

S’APPLIQUE À : Azure Database pour PostgreSQL – Serveur flexible

Cet article passe en revue les options et les meilleures pratiques pour accélérer pg_dump et pg_restore. Il explique également les meilleures configurations de serveur pour effectuer pg_restore.

Meilleures pratiques pour pg_dump

Vous pouvez utiliser l’utilitaire pg_dump pour extraire une base de données de serveur flexible Azure Database pour PostgreSQL dans un fichier script ou un fichier d’archive. Quelques options de ligne de commande que vous pouvez utiliser pour réduire le temps de vidage global à l’aide de pg_dump sont répertoriées dans les sections suivantes.

Format de répertoire(-Fd)

Cette option génère une archive au format de répertoire que vous pouvez entrer dans pg_restore. Par défaut, la sortie est compressée.

Travaux parallèles(-j)

Avec pg_dump, vous pouvez exécuter des travaux de vidage sur incident simultanément à l’aide de l’option travaux parallèles. Cette option réduit le temps de vidage global, mais augmente la charge sur le serveur de base de données. Nous vous recommandons d’arriver à une valeur de travail parallèle après avoir étroitement suivi les indicateurs de performance du serveur source, telles que l’utilisation du processeur, de la mémoire et des IOPS (opérations d’entrée/sortie par seconde).

Lorsque vous définissez une valeur pour l’option travaux parallèles, pg_dump nécessite les éléments suivants :

Le nombre de connexions doit être égal au nombre de travaux parallèles +1. Veillez donc à définir la valeur max_connections en conséquence.
Le nombre de travaux parallèles doit être inférieur ou égal au nombre de processeurs virtuels alloués au serveur de base de données.

Compression(-Z0)

Cette option spécifie le niveau de compression à utiliser. Zéro signifie aucune compression. La compression zéro pendant le processus pg_dump peut vous aider à améliorer les performances.

Ballonnements de table et nettoyage

Avant de démarrer le processus pg_dump, évaluez si le nettoyage de table est nécessaire. Le ballonnement sur les tables augmente considérablement la durée du processus pg_dump. Exécutez la requête ci-dessous pour identifier les ballonnements de table :

select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;

La colonne dead_pct de cette requête indique le pourcentage de tuples morts par rapport aux tuples vivants. Une valeur dead_pct élevée pour une table peut indiquer que le nettoyage de la table ne s’effectue pas correctement. Pour plus d’informations, consultez Réglage du nettoyage automatique dans Azure Database pour PostgreSQL – Serveur flexible.

Pour chaque table que vous identifiez, vous pouvez effectuer une analyse manuelle du vide en suivant la méthode décrite ci-après :

vacuum(analyze, verbose) <table_name>

Utiliser un serveur PITR

Vous pouvez effectuer un pg_dump sur un serveur en ligne ou en direct. Elle effectue des sauvegardes cohérentes même si la base de données est utilisée. Elle n’empêche pas d’autres utilisateurs d’utiliser la base de données. Tenez compte de le la taille de la base de données et d’autres besoins métier ou clients avant de démarrer le processus pg_dump. Les petites bases de données peuvent être utiles pour effectuer un pg_dump sur le serveur de production.

Pour les bases de données volumineuses, vous pouvez créer un serveur PITR (Récupération jusqu`à une date et heure) à partir du serveur de production et effectuer le processus pg_dump sur le serveur PITR. L’exécution de pg_dump sur un PITR serait un processus d’exécution à froid. Le compromis pour cette approche est que vous ne soyez pas préoccupé par l’utilisation supplémentaire du processeur, de la mémoire et des E/S qui accompagne un processus pg_dump s’exécutant sur un serveur de production réel. Vous pouvez exécuter pg_dump sur un serveur PITR, puis supprimer le serveur PITR une fois le processus pg_dump terminé.

Syntaxe pour pg_dump

Utilisez la syntaxe suivante pour pg_dump :

pg_dump -h <hostname> -U <username> -d <databasename> -Fd -j <Num of parallel jobs> -Z0 -f sampledb_dir_format

Meilleures pratiques pour pg_restore

Vous pouvez utiliser l’utilitaire pg_restore pour restaurer une base de données de serveur flexible Azure Database pour PostgreSQL à partir d’une archive créée par pg_dump. Quelques options de ligne de commande pour réduire le temps de restauration global sont répertoriées dans les sections suivantes.

Restauration parallèle

En exécutant plusieurs travaux simultanément, vous pouvez réduire le temps nécessaire à la restauration d’une base de données volumineuse sur un serveur cible multi-vCore. Le nombre de travaux peut être égal ou inférieur au nombre de processeurs virtuels alloués au serveur cible.

Paramètres de serveur

Si vous restaurez des données sur un nouveau serveur ou un serveur hors production, vous pouvez optimiser les paramètres de serveur suivants avant d’exécuter pg_restore :

work_mem = 32 MO
max_wal_size = 65 536 (64 GO)
checkpoint_timeout = 3 600 #60min
maintenance_work_mem = 2 097 151 (2 GO)
autovacuum = désactivé
wal_compression = activé

Une fois la restauration terminée, vérifiez que tous ces paramètres sont correctement mis à jour conformément aux exigences en matière de charge de travail.

Remarque

Suivez les recommandations précédentes uniquement s’il y a suffisamment de mémoire et d’espace disque. Si vous avez un petit serveur avec 2, 4 ou 8 vCores, définissez les paramètres en conséquence.

Autres considérations

Désactivez la haute disponibilité (HA) avant d’exécuter pg_restore.
Analysez toutes les tables migrées une fois la restauration terminée.

Syntaxe pour pg_restore

Utilisez la syntaxe suivante pour pg_restore :

pg_restore -h <hostname> -U <username> -d <db name> -Fd -j <NUM> -C <dump directory>

-Fd : format de répertoire.
-j : nombre de travaux.
-C : Commencez la sortie avec une commande pour créer la base de données elle-même, puis vous y reconnecter.

Voici un exemple de la façon dont cette syntaxe peut apparaître :

pg_restore -h <hostname> -U <username> -j <Num of parallel jobs> -Fd -C -d <databasename> sampledb_dir_format

Considérations liées aux machines virtuelles

Créez une machine virtuelle dans la même région et la même zone de disponibilité, de préférence où vous disposez à la fois de vos serveurs cibles et sources. Ou, au minimum, créez la machine virtuelle plus proche du serveur source ou d’un serveur cible. Nous vous recommandons d’utiliser Machines Virtuelles Azure avec un disque SSD local hautes performances.

Pour plus d’informations sur les références SKU, consultez :