Problem mit archive_command

Hallo zusammen,

kann mir mal bitte jemand sagen, warum folgendes archive_command immer einen Fehlercode 1 verursacht und die ganzen Dateien in pg_xlog nicht kopiert werden?

'copy %p C:\\Archiv\\DBArchiv\\%f'
 

Danke!

Kannst Du es händisch machen, als pg-User? Beginnt Dein Vorname zufällig mit Ch. und habe ich das heute schon in einer Mail gelesen?

Andreas

Ja, es ist sehr wahrscheinlich, dass du das heute bzw. gestern schon mal in einer Mail gelesen hast :wink:
Händisch geht es komischerweise und der pg-user hat auch Vollzugriff auf das Verzeichnis. Noch komischer ist, dass in dem Verzeichnis Dateien von vor ca. 2 Wochen waren und ich seit über einem Jahr dieselben Einstellungen bzgl. archive_command habe.
Was passiert eigentlich wenn man das archive_command auskommentiert? Wird dann pg_xlog zugemüllt oder werden die Dateien in regelmäßigen Abständen gelöscht?

Gelöscht. Bzw. recycelt :wink:

Diese Fehlermeldung, kommt die von PG oder vom OS? Ich verwende da ein scp, um die wegzukopieren. Klappt wunderbar, allerdings verwende ich ein etwas anderes OS als Du.
Hast Du irgend was verändert? Brandschutzmauer, Virenscanner oder sowas?

Aber vielleicht weiß ja fristo oder wer anders da noch einen guten Rat.

Andreas

Die Fehlermeldung steht im pg_log. Aber ich denke mal, dass ich zumindest vorübergehend das archive_command wieder entferne, weil meine DB ohnehin ziemlich statisch ist…

@akretschmer, @ads

Ich benötige mal Detail-Informationen zum “achive_command”. Die Beschreibung in der aktuellen Doku ist nicht eindeutig und die Angaben des “archive_command” für Windows sind absoluter Schrott. Zudem auch ungetestet.

Soll der Copy-Befehl die einzelnen Dateien aus pg_xlog in einem anderem Verzeichnis sichern? Also eine 1:1 Kopie?

Soll der Copy-Befehl die Dateien aus pg_xlog an eine Datei im Sicherungsverzeichnis anhängen (Append)?

Ist %f = dateiname, der Name der Datei entsprechend der Datei in pg_xlog?





mfg

fristo

Patch für die Doku schon eingereicht?

Soll der Copy-Befehl die einzelnen Dateien aus pg_xlog in einem anderem Verzeichnis sichern? Also eine 1:1 Kopie?

Zuerst einmal: in pg_xlog stehen die WAL-Dateien, also die Write Ahead Logs. Grob formuliert, man kann ausgehend von einem vollständigem Backup und den seit diesem Zeitpunkt geschriebenen wal-files ein Restore der DB durchführen. Diese Dateien haben immer eine feste Größe von 16 MByte (sofern nicht anders eingestellt)
Mehr dazu:
PostgreSQL: Documentation: Manuals: PostgreSQL 8.2: Continuous Archiving and Point-In-Time Recovery (PITR)

Soll der Copy-Befehl die Dateien aus pg_xlog an eine Datei im Sicherungsverzeichnis anhängen (Append)?

Nicht anhängen, nur hinkopieren.

Und ja: man muß sich auch kümmern, daß das im Ziel nicht überläuft.

Ist %f = dateiname, der Name der Datei entsprechend der Datei in pg_xlog?

%p mit Pfad, %f nur die Datei, ja.



Andreas

Aus der Dokumentation meiner PITR HA Lösung:

# parameters:
#  - pathname for the logfile (%p in PG)
#  - filename of the logfile (%f in PG)
# return:
#  - 0 if ok
#  - 1 if error
# notes:
#  - %p is relative to the data directory
#  - in case an error occured a nonzero exit status MUST be returned
#    PostgreSQL will try again from time to time to save the logfile

Du musst die Dateien woanders hinsichern, ja. Nachdem archive_command ohne Fehler zurückgekehrt ist, darf PostgreSQL die Logdatei überschreiben: sie ist ja woanders hin gesichert.

%p ist der komplette Pfadname des Logfiles relativ zum data Directory.
%f ist nur der Dateiname allein.

Ich lasse an mein Script, das als archive_command eingetragen ist, beide Parameter übergeben. Das billigste Archive Command wäre demnach (unter Unix):

chdir $data && cp %p /backup/pfad/%f

Wenn cp gut geht, wird 0 zurückgeliefert und alles ist ok. Geht etwas schief, wird != 0 zurückgegeben und PG hebt das Logfile auf und probiert es weiter.

An eine andere Datei anhängen bringt dir nichts, weil du beim Restore wieder genau die Dateien mit den Namen brauchst, die du mit archive_command wegsicherst.