79 votes

PostgreSQL: l'amélioration de pg_dump, pg_restore performance

Quand j'ai commencé, j'ai utilisé pg_dump avec la valeur par défaut de la plaine format. J'ai été mal informé.

La recherche a révélé à moi le temps et la taille du fichier améliorations pg_dump -Fc | gzip -9 -c > dumpfile.gz. J'ai été éclairé.

Quand il est venu le temps de créer la base de données à nouveau,

# 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 me sentais mal informé: de la restauration, qui a duré 12 heures pour créer la base de données qui est seulement une fraction de ce qu'il va devenir:

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

Parce qu'il y a des prédictions de cette base de données sera un peu de téraoctets, j'ai besoin de regarder à l'amélioration de la performance, maintenant.

S'il vous plaît, m'éclairer.

57voto

Ants Aasma Points 22921

Vérifiez d'abord que vous êtes l'obtention raisonnable de performances à partir de votre disque d'installation. Ensuite, vérifiez que vous installation de PostgreSQL est convenablement réglé. En particulier, shared_buffers doit être réglé correctement, maintenance_work_mem devrait être augmenté au cours de la restauration, full_page_writes doit être éteint pendant la restauration, wal_buffers devrait être augmenté de 16 MO au cours de la restauration, checkpoint_segments devrait être porté à quelque chose comme 16 au cours de la restauration, vous ne devriez pas avoir déraisonnable de journalisation (comme l'exploitation forestière à chaque exécution d'une instruction), auto_vacuum doit être désactivée pendant la restauration.

Si vous êtes sur de 8,4 également expérimenter avec le parallèle de la restauration, --les travaux de l'option pour pg_restore.

14voto

Matthew Wood Points 4485

Deux questions/idées:

  1. En spécifiant-Fc, la pg_dump de sortie est déjà compressé. La compression n'est pas maximale, de sorte que vous pouvez trouver certains des économies d'espace à l'aide de "gzip -9", mais je parierais que c'est pas assez pour justifier le temps supplémentaire (et I/O) ont utilisé la compression et la décompression de l'-Fc version de la sauvegarde.

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

10voto

Tometzky Points 8230

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

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

  1. Configurer l'archivage des WAL.

  2. Faites vos sauvegardes de base par exemple chaque jour 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 la restauration de la base de données et WAL journaux datant de moins pg_start_backup du temps à partir de l'emplacement de la sauvegarde et de départ Postgres. Et il sera beaucoup plus rapide.

7voto

richo Points 3238
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 le goulot d'étranglement.

3voto

Will Hartung Points 57465

Comme vous l'aurez deviné simplement par le fait que la compression de la sauvegarde des résultats dans des performances plus rapides, votre sauvegarde est I/O bound. Cela devrait venir en tant qu'aucune surprise que la sauvegarde est à peu près toujours d'e/s. Compression des données métiers de la charge d'e/S pour la charge CPU, et puisque la plupart des Processeurs sont au repos pendant monstre transferts de données, la compression ne sort qu'à un gain net.

Donc, à la vitesse de la sauvegarde/restauration, vous avez besoin plus rapidement I/O. au-Delà de la réorganisation de la base de données afin de ne pas être un énorme seule instance, c'est à peu près tout ce que vous pouvez faire.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X