Als ich anfing, habe ich pg_dumpdas Standardformat verwendet. Ich war nicht erleuchtet.

Nachforschungen haben mir Zeit- und Dateigrößenverbesserungen mit ergeben pg_dump -Fc | gzip -9 -c > dumpfile.gz. Ich wurde erleuchtet.

Wenn es an der Zeit war, die Datenbank neu zu erstellen,

# 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

Ich fühlte mich nicht aufgeklärt: Die Wiederherstellung dauerte 12 Stunden, um die Datenbank zu erstellen, die nur einen Bruchteil dessen darstellt, was daraus werden wird:

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

Da es Vorhersagen gibt, dass diese Datenbank einige Terabyte groß sein wird, muss ich mich jetzt mit der Verbesserung der Leistung befassen.

Bitte erleuchte mich.

Überprüfen Sie zunächst, ob Sie von Ihrem Festplatten-Setup eine angemessene E / A-Leistung erhalten. Überprüfen Sie anschließend, ob Ihre PostgreSQL-Installation ordnungsgemäß optimiert ist. Insbesondere shared_bufferssollte richtig eingestellt sein, maintenance_work_memsollte während der Wiederherstellung erhöht werden, sollte während der Wiederherstellung ausgeschaltet sein, full_page_writessollte während der Wiederherstellung wal_buffersauf 16 MB erhöht werden, sollte während der Wiederherstellung checkpoint_segmentsauf etwa 16 MB erhöht werden, sollten Sie keine unangemessene Anmeldung haben (wie das Protokollieren jeder ausgeführten Anweisung), auto_vacuumsollte während der Wiederherstellung deaktiviert werden.

Wenn Sie unter 8.4 auch mit paralleler Wiederherstellung experimentieren, verwenden Sie die Option --jobs für pg_restore.

Verbessern Sie pg dump & restore

PG_DUMP | Verwenden Sie immer das Formatverzeichnis und die -jOptionen

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

PG_RESTORE | Verwenden Sie immer die Optimierung für postgres.conf und das Formatverzeichnis und die -jOptionen

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/

Zwei Themen / Ideen:

1. Durch Angabe von -Fc wird die Ausgabe von pg_dump bereits komprimiert. Die Komprimierung ist nicht maximal, daher können Sie durch die Verwendung von "gzip -9" einige Platzersparnisse erzielen. Ich würde jedoch wetten, dass dies nicht ausreicht, um die zusätzliche Zeit (und E / A) für das Komprimieren und Dekomprimieren der -Fc-Version des Backups zu gewährleisten .

2. Wenn Sie PostgreSQL 8.4.x verwenden, können Sie die Wiederherstellung aus einer -Fc-Sicherung möglicherweise mit der neuen Befehlszeilenoption "-j n" von pg_restore beschleunigen, wobei n = Anzahl der für die Wiederherstellung zu verwendenden parallelen Verbindungen ist. Dadurch kann pg_restore mehr als die Daten einer Tabelle laden oder mehr als einen Index gleichzeitig generieren.

Ich gehe davon aus, dass Sie ein Backup benötigen, kein größeres Upgrade der Datenbank.

Für die Sicherung großer Datenbanken sollten Sie stattdessen eine kontinuierliche Archivierung einrichten pg_dump.

1. Richten Sie die WAL-Archivierung ein .

2. 
   psql template1 -c "select pg_start_backup('Erstellen Sie Ihre Basissicherungen beispielsweise jeden Tag mit `date +% F-% T`` ')" rsync -a --delete / var / lib / pgsql / data / / var / backups / pgsql / base / psql template1 - c "wähle pg_stop_backup ()" `

Eine Wiederherstellung ist so einfach wie das Wiederherstellen von Datenbank- und WAL-Protokollen, die nicht älter als die pg_start_backupZeit vom Sicherungsspeicherort sind, und das Starten von Postgres. Und es wird viel schneller sein.

zcat dumpfile.gz | pg_restore -d db_name

Entfernt das vollständige Schreiben der nicht komprimierten Daten auf die Festplatte, was derzeit Ihr Engpass ist.

Wie Sie vielleicht einfach aufgrund der Tatsache erraten haben, dass das Komprimieren des Backups zu einer schnelleren Leistung führt, ist Ihr Backup an die E / A gebunden. Dies sollte nicht überraschen, da Backups so gut wie immer an E / A gebunden sind. Durch das Komprimieren der Daten wird die E / A-Last gegen die CPU-Last ausgetauscht. Da die meisten CPUs während der Monsterdatenübertragung im Leerlauf sind, wird die Komprimierung als Nettogewinn gewertet.

Um die Sicherungs- / Wiederherstellungszeiten zu verkürzen, benötigen Sie schnellere E / A. Abgesehen davon, dass die Datenbank so umstrukturiert wird, dass sie keine einzige Instanz ist, können Sie so ziemlich alles tun.