WAL-Archivierung

Hallo zusammen,

auf einem Windows-System läuft ein PG-DBS 8.3.7 und soll die WAL archivieren. Der Server hat das auch eine ganze Weile hervorragend gemacht (2 Tage), seit einigen Stunden versucht das PG jedoch WAL-Files, welche bereits wegkopiert waren, erneut zu kopieren. Im Protokoll sieht das so aus:

2010-02-01 16:52:31 CET LOG:  archive command failed with exit code 1
2010-02-01 16:52:31 CET DETAIL:  The failed archive command was: cp D:/meditec/PostgreSQL/8.3/data/pg_xlog/0000000100000006000000C0 D:/meditec/backup/tx_log/0000000100000006000000C0 1>>archive.log 2>&1
2010-02-01 16:52:33 CET LOG:  archive command failed with exit code 1
2010-02-01 16:52:33 CET DETAIL:  The failed archive command was: cp D:/meditec/PostgreSQL/8.3/data/pg_xlog/0000000100000006000000C0 D:/meditec/backup/tx_log/0000000100000006000000C0 1>>archive.log 2>&1
2010-02-01 16:52:34 CET LOG:  archive command failed with exit code 1
2010-02-01 16:52:34 CET DETAIL:  The failed archive command was: cp D:/meditec/PostgreSQL/8.3/data/pg_xlog/0000000100000006000000C0 D:/meditec/backup/tx_log/0000000100000006000000C0 1>>archive.log 2>&1
2010-02-01 16:52:34 CET WARNING:  transaction log file "0000000100000006000000C0" could not be archived: too many failures

In meinem Archivierungslog steht Folgendes:

cp: cannot stat `D:/meditec/PostgreSQL/8.3/data/pg_xlog/0000000100000006000000C0': No such file or directory
cp: cannot stat `D:/meditec/PostgreSQL/8.3/data/pg_xlog/0000000100000006000000C0': No such file or directory
cp: cannot stat `D:/meditec/PostgreSQL/8.3/data/pg_xlog/0000000100000006000000C0': No such file or directory

Im letzten Backup-File steht das:

START WAL LOCATION: 6/E6191010 (file 0000000100000006000000E6)
STOP WAL LOCATION: 6/E695D6C8 (file 0000000100000006000000E6)
CHECKPOINT LOCATION: 6/E63009F8
START TIME: 2010-02-01 16:29:32 CET
LABEL: pg_basebackup
STOP TIME: 2010-02-01 16:37:09 CET

Nun meine Frage, warum versucht PG diese Files noch einmal in das Archiv zu kopieren?

Wenn ich die WAL-Files, die lt. Protokoll nicht kopiert werden können (weil sie ja nicht mehr im Ordner pg_xlog liegen), per Hand zurück schiebe, werden sie kopiert und es geht mit der nächsten weiter…

Btw.: Sollte nicht nach einem erneuten BaseBackup (inkl. select pg_start_backup(‘xxx’) und select pg_stop_backup()) alles , was davor gelaufen ist, egal sein??? Die Logfiles von vor drei Tagen interessieren doch gar nicht mehr…?


Bin für jede Hilfe dankbar!

2 Tage? Ist nicht gerade eine lange Zeit …

Egal: PostgreSQL wird versuchen, die Datei wieder zu sichern, wenn das nicht funktioniert hat. Ausschlaggebend dafür ist der Rückgabecode von “archive_command”. Gibt es “weiter oben” im Logfile noch andere Fehlermeldungen?

2 Tage? Ist nicht gerade eine lange Zeit …

Stimmt, aber es lief und hat ca. 1000 WAL-Files kopiert :astonished:

Fehlermeldung gibt es keine, aber die Dateien wurde ja auch schon wegkopiert… Eigentlich gibt es keinen Grund, diese nochmal kopieren zu wollen. Im Prinzip kann nur der Rückgabewert des archive_commands das auslösen, aber bei einem simplen cp sollte der doch 0 sein.

Na ja, 1000 WAL-Dateien habe ich manchmal in 2 Stunden :wink:

Nun, um das Problem zu umgehen, schreibt man sich ein eigenes Skript, dass den Rückgabewert prüft und entsprechend loggt. Alles, was du auf STDERR ausgibst (hat Windows so was überhaupt) wandert in das Log der Datenbank. Brauchst du also kein eigenes Log dafür zu schreiben. Ach so, und ich überprüfe auch vorher, ob es die Zieldatei schon gibt und ob die gleich ist. Dann fange ich a) solche Fehler und b) Probleme mit ggf. mehreren Datenbanken gleich mit ab.

Gerade weil du annimmst, dass irgendwas nicht mit dem Rückgabewert in Ordnung ist, frage ich ja, ob es schon früher im Log Fehlermeldungen gab.

STDERR gibt es, im Moment logge ich STDOUT und STDERR mit.
Wie kann ich das denn in das zur Laufzeit gültige DB-Log schreiben, das heißt doch andauernd anders… :wink: Gibt es da einen Trick?

Ja, einfach auf STDERR schreiben. Die Datenbank kümmert sich um den Rest und leitet das dorthin. Steht aber auch in der Dokumentation.

Du selbst solltest tunlichst überhaupt nicht in das Logfile schreiben.

So, Sport vorbei… kann ich mich wieder um das Wesentliche kümmern ;.)

An das mit dem STDERR kann ich mich jetzt sogar erinnern, das kann mal ja im Config-File auch einstellen…

Noch eine wichtige Frage: Wie kriege ich den Schlamassel denn nun wieder hin? Ich kann ja nicht jedes File einzeln aus dem Archiv zurückkopieren, um nochmal zu archivieren.
Mögliche Lösung: Kann ich ein neues Basisbackup machen und die ab dann produzierten WAL-Files wegsichern??? Oder will der PG-Server auf Teufel-komm-raus alles kopieren?

Deine Mögliche Lösung funktioniert.

Beseitigt allerdings nur dein aktuelles Problem. Du weißt nicht, wie der Fehler auftrat und ob das noch mal passieren kann.

Das werde ich morgen testen. Erstaunlich finde ich nur, dass dieses Problem erst unter Last aufgetreten ist… Na mal sehen…
Habe gerade schon einmal mit den Returnwerten rumgebastelt, das kriegt man auch aus Windows-Batchfiles prima zurück.

Werde dann mein Ergebnis posten.

@ads: Vielen Dank!!!