web-dev-qa-db-fra.com

PostgreSQL: amélioration des performances de pg_dump, pg_restore

Quand j'ai commencé, j'ai utilisé pg_dump avec le format standard par défaut. Je n'étais pas éclairé.

Des recherches m'ont révélé des améliorations de temps et de taille de fichier avec pg_dump -Fc | gzip -9 -c > dumpfile.gz. J'étais éclairé.

Quand est venu le temps de recréer la base de données,

# create tablespace dbname location '/SAN/dbname';
# create database dbname tablespace dbname;
# alter database dbname set temp_tablespaces = dbname;

% gunzip dumpfile.gz              # to evaluate restore time without a piped uncompression
% pg_restore -d dbname dumpfile   # into a new, empty database defined above

Je ne me sentais pas éclairé: la restauration a pris 12 heures pour créer la base de données qui n'est qu'une fraction de ce qu'elle deviendra:

# select pg_size_pretty(pg_database_size('dbname'));
47 GB

Parce qu'il y a des prédictions que cette base de données sera de quelques téraoctets, je dois maintenant chercher à améliorer les performances.

Veuillez m'éclairer.

performancepostgresqlbackuprestore
68
Joe Creighton

Vérifiez d'abord que vous obtenez des performances IO raisonnables à partir de la configuration de votre disque. Vérifiez ensuite que votre installation PostgreSQL est correctement réglée. En particulier shared_buffers doit être défini correctement, maintenance_work_mem devrait être augmenté pendant la restauration, full_page_writes devrait être désactivé pendant la restauration, wal_buffers devrait être porté à 16 Mo lors de la restauration, checkpoint_segments devrait être augmenté à quelque chose comme 16 pendant la restauration, vous ne devriez pas avoir de connexion déraisonnable (comme la journalisation de chaque instruction exécutée), auto_vacuum doit être désactivé pendant la restauration.

Si vous êtes sur 8.4, essayez également la restauration parallèle, l'option --jobs pour pg_restore.

49
Ants Aasma

Deux problèmes/idées:

  1. En spécifiant -Fc, la sortie pg_dump est déjà compressée. La compression n'est pas maximale, vous pouvez donc trouver des économies d'espace en utilisant "gzip -9", mais je parierais que ce n'est pas suffisant pour garantir le temps supplémentaire (et les E/S) utilisé pour compresser et décompresser la version -Fc de la sauvegarde .

  2. Si vous utilisez PostgreSQL 8.4.x, vous pouvez potentiellement accélérer la restauration à partir d'une sauvegarde -Fc avec la nouvelle option de ligne de commande pg_restore "-j n" où n = nombre de connexions parallèles à utiliser pour la restauration. Cela permettra à pg_restore de charger plus de données d'une table ou de générer plus d'un index en même temps.

14
Matthew Wood

Améliorer le vidage et la restauration de pg

PG_DUMP | utilisez toujours le répertoire de format avec -j option

time pg_dump -j 8 -Fd -f /tmp/newout.dir fsdcm_external

PG_RESTORE | utilisez toujours le réglage pour postgres.conf avec le répertoire de format Avec -j option

work_mem = 32MB
shared_buffers = 4GB
maintenance_work_mem = 2GB
full_page_writes = off
autovacuum = off
wal_buffers = -1

time pg_restore -j 8 --format=d -C -d postgres /tmp/newout.dir/`

Pour plus d'informations

https://github.com/YanarAssaf/PostgreSQL/wiki/Improve-pg-dump%7Crestore

12
Yanar Assaf

Je suppose que vous avez besoin d'une sauvegarde, pas d'une mise à niveau majeure de la base de données.

Pour la sauvegarde de grandes bases de données, vous devez configurer archivage contin au lieu de pg_dump.

  1. Configurer l'archivage WAL .

  2. Faites vos sauvegardes de base par exemple tous les jours en utilisant
    psql template1 -c "select pg_start_backup('`date +% F-% T '' ') "rsync -a --delete/var/lib/pgsql/data// var/backups/pgsql/base/psql template1 -c" select pg_stop_backup () "`

Une restauration serait aussi simple que de restaurer la base de données et les journaux WAL qui ne sont pas antérieurs à pg_start_backup temps depuis l'emplacement de sauvegarde et le démarrage de Postgres. Et ce sera beaucoup plus rapide.

9
Tometzky
zcat dumpfile.gz | pg_restore -d db_name

Supprime l'écriture complète des données non compressées sur le disque, qui est actuellement votre goulot d'étranglement.

7
richo

Comme vous l'avez peut-être deviné simplement du fait que la compression de la sauvegarde entraîne des performances plus rapides, votre sauvegarde est liée aux E/S. Cela ne devrait pas être surprenant, car la sauvegarde sera presque toujours liée aux E/S. La compression des données échange la charge d'E/S contre la charge du processeur, et comme la plupart des processeurs sont inactifs pendant les transferts de données monstres, la compression est un gain net.

Ainsi, pour accélérer les temps de sauvegarde/restauration, vous avez besoin d'E/S plus rapides. Au-delà de la réorganisation de la base de données pour ne pas être une énorme instance unique, c'est à peu près tout ce que vous pouvez faire.

3
Will Hartung