Partager via

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

  • Article

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 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 sauvegarde, 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 métriques 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 pour le 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 à gagner en performances.

Ballonnements de table et nettoyage

Avant de démarrer le processus pg_dump, décidez si le nettoyage de table est nécessaire. Le ballonnement sur les tables augmente considérablement les heures 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 la table n’est pas correctement vidée. 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 exécutant les commandes suivantes :

vacuum(analyze, verbose) <table_name>

Utiliser un serveur PITR

Vous pouvez effectuer un pg_dump sur un serveur en ligne ou actif. 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. Prenez en compte la taille de la base de données et d’autres besoins métier ou clients avant de démarrer leprocessus 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 fourni avec 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

À l’aide de plusieurs travaux simultanés, 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 pour le 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 de charge de travail.

Notes

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, 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 :

Partager vos suggestions et bogues avec l’équipe produit Azure Database pour PostgreSQL.

Contenu connexe