Backup und Restore incl. WAL

Hallo zusammen,

ich habe hier ein 10GB-DB die ich wie folgt sichere:

pg_dump dbname | gzip > filename.gz

ich habe die DB vorhin zerstört und wie folgt restored:

gunzip -c filename.gz | psql dbname

Hat perfekt funktioniert, dennoch : wenn ich bis hier irgendwas falsch gemacht habe, dann sagt es bitte.

Da ich diese DB in drei Wochen erstmals in Produktion einsetzen soll möchte ich natürlich etwas mehr : PITR.

Ich habe das pg_xlog per Symlink auf eine andere Platte gelegt.
Ich habe als archive_command = ‘cp “%p” /wal.backup/"%f"’.

Jetzt meine Frage : wie muss ich das Backup machen (oder reicht meine Variante) und wie kann ich nach dem Restore des pg_dump meine WALs nachspielen.

Die PG-Doku habe ich gelesen, ich fand diesen Bereich recht spärlich dokumentiert, vielleicht habe ich auch etwas übersehen.

Jeder Hinweis ist willkommen.

cu, Stefan

Hi,

Also bei mir funktionierte das bei meinem Test-System ganz gut. Die Doku ist doch garnicht so schlecht? Hast du schon den Abschnitt gelsesen? :

http://www.postgresql.org/docs/8.1/static/backup-online.html

Ganz grob das backup:

SELECT pg_start_backup(‘meinbackup’);

filesystembackup cpio / rsync etc.

SELECT pg_stop_backup();

Beim restore:

#filesystemrestore
restore.conf anlegen
postgres starten

Du könntest jetzt jedes WE ein Filesystembackup machen und über die Woche die WALs archivieren. Dann bist du auf der ganz sicheren Seite.

OT: Eine andere Variante zu “pgdump” auf der primären maschine:

  • sec-node disconnecten
  • sec-node auf primär setzen
  • postgres starten
  • pgdump
  • postgres stoppen
  • sec-node von primär auf sekundär
  • drbd reconnecten

Vorteil:

  • belastet die primäre DB nicht (außer der DRBD sync)

Bei der WAL-Variante gibts auch noch einen Haken:

If we continuously feed the series of WAL files to another machine that has been loaded with the same base backup file, we have a “hot standby” system: at any point we can bring up the second machine and it will have a nearly-current copy of the database.

Da musst du dir selbst was stricken, denn das ist noch nicht automatisiert. Wird aber in naher Zukunft implementiert so wie ich gehört habe :wink: . Und falls deine DB abschmiert, musst du erst das FS-Backup zurückspielen und postgres den REDO machen lassen. Dann doch lieber DRBD+LVM2 (lvmsnapshot!), dass geht noch am schnellsten?!? Habe LVM aber noch nicht ausführlich mit DRBD getestet :wink: .

Viele Grüße,

pingufreak

Hi,

vielen Dank für deine sehr ausführliche Antwort.
Bemerkenswert für einen Grünschnabel :wink: (wer vergiebt eigentlich diese Rankings ?)

Das mit dem Online-Backup habe ich inzwischen ausprobiert -ist natürlich in einer Produktionsdb weitaus sinnvoller als ein pgdump - und zudem ist das restore auch wesentlich schneller.

Ich muss wahrscheinlich ein wenig damit rumspielen um ein Gefühl dafür zu bekommen.

Eine Frage habe ich dann aber doch noch:

Wenn ich das richtig verstanden habe wird bei stop_backup eine Kopie der Transaktionen erstellt die seit start_backup gemacht wurden, in …/pg_xlog sammeln sich aber die 16M Transaktionsdateien weiter an. Löscht PG diese irgendwann selbsständig oder muss ich hier selbst hand anlegen ?

Ich bin in der postgresql.conf über einen Parameter gestossen (hab den Name grad’ nicht parat) den man von 0-64 setzen konnte. Steuert der das und wenn ja, welcher Wert ist hier sinnvoll ?

Danke nochmal

Stefan

Hi,

ich will ja auch bald mehr als einen Grünschnabel haben :wink: .

Die 16M sind in postgres hardcoded. Kannste vor dem kompilieren oder mit dem source-rpm nachträglich ändern.

Die Anzahl der WALs wird mit der Option checkpoint_segments angegeben. Postgres rotiert dann diese. Es unterscheiden sich dabei archivierte und nicht archivierte WALs. Die archivierten werden per archive_command wegkopiert (auf nem nfs z.B.), die nicht archivierten befinden sich in pg_xlog.

Es gibt keinen empfohlenen Wert für die checkpoint_segments. Guck einfach wieviel Platz du auf der pg_xlog Partition hast, und rechne entsprechend die (2*anzahl+1)*16 hoch. Dann testest du die Performance. Ist die Performance zu schwach, setze checkpoing_segments runter und teste nochmal. Sollte die folgende Meldung kommen: ¨Checkpoints passieren zu oft (alle x Sekunden)", dann setze die Anzahl wieder ein bisschen höher. Das kommt ganz drauf an wieviele Transaktionen durch deine DB flitzen.

Tipp:
Falls postgres nicht startet, weil kein gültiger checkpoint in den WALs gefunden wird, postgres stoppen und pg_resetxlog ausführen.

Viele Grüße,

pingufreak

jetzt bin ich rundrum glücklich :smiley:

danke, stefan

hallo,

habe ich das so richtig verstanden.

nach einem SELECT pg_start_backup(‘meinbackup’); führt der db-server keine änderungen mehr an den datendateien durch, sondern läßt alles in den transaktionslogs stehen (er macht also kein checkpoint mehr).

nach dem pg_stop_backup zieht der dann die änderungen nach.

hab ich das so richtig verstanden?

Viele Grüße
Kevin