Also bei mir funktionierte das bei meinem Test-System ganz gut. Die Doku ist doch garnicht so schlecht? Hast du schon den Abschnitt gelsesen? :
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 . 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 .
vielen Dank für deine sehr ausführliche Antwort.
Bemerkenswert für einen Grünschnabel (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 ?
ich will ja auch bald mehr als einen Grünschnabel haben .
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.
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.