it-swarm.com.de

PostgreSQL: Verbesserung der Leistung von pg_dump und pg_restore

Als ich anfing, benutzte ich pg_dump mit dem normalen Standardformat. Ich war nicht aufgeklärt.

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

Als 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 ein paar Terabyte groß sein wird, muss ich jetzt die Leistung verbessern.

Bitte erleuchte mich.

68
Joe Creighton

Überprüfen Sie zunächst, ob Ihre Festplattenkonfiguration eine angemessene IO Leistung erbringt. Vergewissern Sie sich dann, dass Ihre PostgreSQL-Installation richtig eingestellt ist. Insbesondere sollte shared_buffers Richtig eingestellt sein, maintenance_work_mem Sollte während der Wiederherstellung erhöht werden, full_page_writes Sollte während der Wiederherstellung deaktiviert sein, wal_buffers Sollte auf 16 MB erhöht werden Während der Wiederherstellung sollte checkpoint_segments auf 16 erhöht werden. Während der Wiederherstellung sollte keine unangemessene Anmeldung erfolgen (wie bei jeder ausgeführten Anweisung). auto_vacuum sollte während der Wiederherstellung deaktiviert werden .

Wenn Sie in 8.4 auch mit der parallelen Wiederherstellung experimentieren, verwenden Sie die Option --jobs für pg_restore.

49
Ants Aasma

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 mit "gzip -9" Platz sparen, aber ich wette, es ist nicht genug, um die zusätzliche Zeit (und die E/A) für das Komprimieren und Dekomprimieren der -Fc-Version des Backups zu garantieren .

  2. Wenn Sie PostgreSQL 8.4.x verwenden, können Sie möglicherweise die Wiederherstellung von einer -Fc-Sicherung mit der neuen Befehlszeilenoption "-j n" beschleunigen, wobei n die 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.

14
Matthew Wood

Verbessere pg dump & restore

PG_DUMP | benutze immer das Formatverzeichnis mit -j Möglichkeit

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

PG_RESTORE | benutze immer tuning für postgres.conf mit format directory With -j Möglichkeit

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/`

Für mehr Information

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

12
Yanar Assaf

Ich gehe davon aus, dass Sie ein Backup benötigen, keine größere Aktualisierung der Datenbank.

Für die Sicherung großer Datenbanken sollten Sie kontinuierliche Archivierung anstelle von pg_dump Einrichten.

  1. WAL-Archivierung einrichten .

  2. Erstellen Sie Ihre Basissicherungen zum Beispiel jeden Tag mit
    psql template1 -c "select pg_start_backup(' `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_backup - Zeit vom Sicherungsspeicherort und dem Starten von Postgres sind. Und es wird viel schneller sein.

9
Tometzky
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.

7
richo

Wie Sie vielleicht einfach aufgrund der Tatsache erraten haben, dass das Komprimieren der Sicherung zu einer schnelleren Leistung führt, ist Ihre Sicherung an die E/A gebunden. Dies sollte nicht überraschen, da Backups so gut wie immer I/O-gebunden sind. Beim Komprimieren der Daten wird die E/A-Last durch die CPU-Last ersetzt. Da die meisten CPUs während der Monster-Datenübertragung im Leerlauf sind, wird die Komprimierung als Nettogewinn ausgewiesen.

Um die Sicherungs-/Wiederherstellungszeiten zu beschleunigen, benötigen Sie schnellere E/A-Vorgänge. Abgesehen davon, dass Sie die Datenbank so reorganisieren, dass sie nicht nur eine einzige große Instanz ist, können Sie so ziemlich alles tun.

3
Will Hartung