2010-01-19 11 views
62

Als ich anfing, habe ich pg_dump mit dem Standard-Plain-Format verwendet. Ich war nicht erleuchtet.PostgreSQL: Verbesserung pg_dump, pg_restore Leistung

Forschung ergab mir Zeit und Dateigröße Verbesserungen mit pg_dump -Fc | gzip -9 -c > dumpfile.gz. Ich war erleuchtet.

Als es Zeit war erneut die Datenbank 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 unaufgeklärten: die 12 Stunden dauerte Wiederherstellen der Datenbank zu erstellen, die nur ein Bruchteil dessen, was es werden wird:

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

Da es Vorhersagen gibt, dass diese Datenbank ein paar Terabyte sein wird, muss ich jetzt die Performance verbessern.

Bitte, erleuchte mich.

Antwort

45

Überprüfen Sie zunächst, ob Sie von der Festplatteneinrichtung eine angemessene E/A-Leistung erhalten. Dann überprüfen Sie, ob Sie die PostgreSQL-Installation entsprechend abgestimmt haben. Insbesondere shared_buffers sollte 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 16MB während der Wiederherstellung erhöht werden, checkpoint_segments sollte auf etwas wie 16 während der Wiederherstellung erhöht werden, sollten Sie nicht Wenn Sie sich unangemessen anmelden (wie das Protokollieren jeder ausgeführten Anweisung), sollte auto_vacuum während der Wiederherstellung deaktiviert werden.

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

+0

Wenn Sie einen Slave angeschlossen haben und die Last auf dem Master bereits beträchtlich ist, dann sollten Sie stattdessen nur das Backup auf dem Slave durchführen. Zumal der Slave schreibgeschützt ist, kann ich mir vorstellen, dass das auch in gewissem Maße helfen kann. In einem großen Cluster kann es hilfreich sein, einen oder mehrere Slaves für gestaffelte Backups einzurichten, wenn die Backups sehr lange dauern. Damit Sie nichts verpassen, möchten Sie, dass diese Standby-Geräte über Streaming-Replikation verbunden sind, sodass sie von der WAL auf dem Master beschrieben werden. –

+5

'shared_buffers sollte richtig eingestellt sein' was bedeutet das? –

3

Wie Sie vielleicht schon daran gewöhnt haben, dass das Komprimieren der Sicherung zu einer schnelleren Leistung führt, ist Ihr Backup I/O-gebunden. Dies sollte nicht überraschen, da Backups immer mit E/A-Verbindungen verbunden sind. Das Komprimieren der Datenhandel-I/O-Last für die CPU-Last und da die meisten CPUs während Monster-Datenübertragungen inaktiv sind, kommt die Komprimierung als ein Nettogewinn heraus.

Um die Backup-/Wiederherstellungszeiten zu beschleunigen, benötigen Sie schnellere E/A. Abgesehen davon, dass Sie die Datenbank neu organisieren müssen, um keine einzige große Instanz zu sein, können Sie so ziemlich alles tun.

+0

Wenn nur die pg_dump Zeit zu optimieren, mit parallelen Dump ab v9.3, Kompression> 0 kann sehr weh tun! Dies liegt daran, dass pg_dump- und postmaster-Prozesse die CPU bereits so weit schwächen, dass das Hinzufügen von Komprimierung> = 1 die Gesamtaufgabe erheblich CPU-gebunden anstatt I/O-gebunden macht. Grundsätzlich ist die ältere Annahme, dass die CPUs ohne Komprimierung im Leerlauf sind, mit parallelem Dump ungültig. –

13

Zwei Fragen/Ideen:

  1. Durch -Fc Angabe wird die pg_dump Ausgang bereits komprimiert. Die Komprimierung ist nicht maximal, daher können Sie durch die Verwendung von "gzip -9" Speicherplatz einsparen, aber ich wette, dass dies nicht ausreicht, um die zusätzliche Zeit (und I/O) für die Komprimierung und Dekomprimierung 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 pg_restore "-j n" beschleunigen, wobei n = Anzahl der für die Wiederherstellung zu verwendenden parallelen Verbindungen. Dadurch kann pg_restore mehr als eine Tabelle laden oder mehr als einen Index zur gleichen Zeit generieren.

+0

Wir sind derzeit bei 8,3; neuer Grund für ein Upgrade –

+0

Sie können die 8.4-Version von pg_restore mit einer 8.3-Version des Servers verwenden. Stellen Sie sicher, dass Sie pg_dump von 8.3 verwenden. –

+0

Bah. Wir sind bei 8.3 festgefahren, weil wir die Solaris10-Paket-Installation von Postgres verwenden und "es ist derzeit nicht geplant, PG8.4 in S10 zu integrieren." [Ref. http://www.mail-archive.com/[email protected]/msg136829.html] Ich müsste die Aufgabe übernehmen, die Open-Source Postgres zu installieren und zu warten. Unsicher, ob wir das hier machen können ... Feh. –

8

Ich nehme an, Sie brauchen Backup, kein großes Upgrade der Datenbank.

Für die Sicherung großer Datenbanken sollten Sie continuous archiving anstelle von pg_dump einrichten.

  1. Set up WAL archiving.

  2. Machen Sie Ihre Basis-Backups zum Beispiel jeden Tag von
    psql template1 -c "select pg_start_backup(' `date +% F-% T`` ')“ rsync -a --delete/var/lib/pgsql/data// var/Sicherungen/pgsql/base/ psql template1 -c "wählen pg_stop_backup()" `

A wiederherstellen würde die Wiederherstellung Datenbank so einfach sein und WAL protokolliert nicht älter als pg_start_backup Zeit von Backup-Speicherort und starten Postgres. und es wird viel schneller sein

+1

Wir haben uns PITR (WAL-Archivierung) nicht angesehen, da das System nicht sehr transaktionsintensiv ist, sondern stattdessen viele historische Aufzeichnungen speichert. Aber jetzt, wo ich darüber nachdenke, kann ein "inkrementelles" Backup helfen. Ich werde untersuchen. Vielen Dank. –

-1

Zusätzlich zu der o Weitere Vorschläge, vergessen Sie nicht, Ihre Konfiguration zu optimieren, einschließlich Änderungen an maintenance_work_mem und checkpoint_segments.

Die Leistungshinweise für das Einfügen von Daten in PostgreSQL finden Sie unter this page.

8

Entfernt das vollständige Schreiben der unkomprimierten Daten auf die Festplatte, die derzeit der Engpass ist.

4

pg Dump verbessern &

Pg_dump wiederherstellen | immer verwenden Format Verzeichnis mit -j Option

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

pg_restore | verwenden Tuning immer für postgres.conf mit Format Verzeichnis Mit -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/` 

Für weitere Informationen

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