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:
In meinem Archivierungslog steht Folgendes:Code: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
Im letzten Backup-File steht das:Code: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
Nun meine Frage, warum versucht PG diese Files noch einmal in das Archiv zu kopieren?Code: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
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!
Geändert von murphy (01.02.2010 um 18:21 Uhr)
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?
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Stimmt, aber es lief und hat ca. 1000 WAL-Files kopiert2 Tage? Ist nicht gerade eine lange Zeit ...
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 ;-)
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.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
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.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
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.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
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!!!
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen