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

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.