WAL Files Ordner läuft über ...

… und was passiert dann??

Ist euch das mal passiert. Ich schreibe schön per Cron Job meine WAL Files weg auf einen anderen Datenträger. Nun was passiert aber, wenn ich die entstandenen WAL Files nicht weg kopiere.

Läuft meine Festplatte über oder überschreibt postgreSQL die alten WAL files???

Situation:

in der postgresql.conf habe ich per archive_command einen Pfad angegeben in den er die WAL Files kopiert. Wenn dieser Ordner nun Überläuft sprich Quota Festplatte ist voll.Was passiert dann?

Von was genau sprichst Du, die originalen oder die, die du wegkopierst?

Die originalen werden recycelt, guggst Du:

Was Du mit denen machst, die Du wegkopierst, ist Deine Sache.

Btw.: die WALs nur in einen anderen Ordner derselben Platte zu kopieren ist keine intelligente Idee. Außer erhöhter Last durch das schreiben hast Du bei Ausfall dieser Platte exakt nix gewonnen. Was anderes ist es, wenn es eine andere Platte ist. Oder ein anderer Rechner.


Andreas

Nee habe alles auf anderen Maschinen und Festplatten usw.
Meine Frage ist eigentlich, was macht PostgreSQL, wenn er in dieses Archiv nicht mehr schreiben kann.

Beispiel:
Maschine 1 -> PostgreSQL
Maschine 2 -> Wal Files

So nun schreibe ich fleißig auf Maschine 2 -> Wal
Was passiert nun, wenn das Verzeichnis/die Platte voll ist ??

Der Prozess, der das machen soll, hat dann ein Problem. PG selbst ist das egal, es quengelt nur im Log rum. Hab mal testweise als Ziel des SCP-Kommandos das CD-Laufwerk angegeben:

2007-01-26 17:15:57 CET  LOG:  00000: archive command "scp "pg_xlog/00 ...... failed: return code 256

Das kommt 3 mal und dann:

2007-01-26 17:15:57 CET  WARNING:  01000: transaction log file "00..." could not be archived: too many failures

Andreas

cool, danke sehr, also ich habe eben mal meine Festplatte gefüllt und wollte auf die Datenbank zum schreiben, dies kann ich mir nun sparen.

Also meine Festplatte ist wieder auf orginal Zustand :smiley:

Okay, wohin kann ich die Rechnung schicken?

Andreas

Archiv Files haben eine feste Größe und diese wird im voraus komplett auf der Platte belegt, wenn die Archivdatei angelegt wird. Sprich, ist die Datei 16 MB groß, werden diese 16 MB gleich reserviert und dann wird nach und nach dort hineingeschrieben. Da PG seine WAL Files sowieso wieder benutzt, besteht hier also kein Problem, deine Transaktionen sind gesichert und nach einem anderweitigen Problem kann der letzte saubere Zustand der Datenbank wieder hergestellt werden.

Probleme bekommst du allerdings, wenn in irgendeine Tabelle neue Einträge geschrieben werden sollen und die Platte ist voll. Dann will die DB nicht mehr (wie auch), aber was exakt dann passiert … nie ausprobiert. Jedenfalls gilt nach Beseitigung des Problems das oben gesagte: die DB kann auf den letzten sauberen Stand aus den Logfiles hergestellt werden.

ads, deine Aufführungen sind richtig.
Aber es ging darum, dass ich Zweck Backup die WAL Files auf eine sep. HDD
schreibe.
Und nun wollte ich wissen, was passiert wenn diese Backup HDD voll ist.

Wenn ich in der postgresql.conf den archive_cp Befehl nicht verwende, schreibt
postgresql die Dateien natürlich in pg_xlog und überschreibt diese per default, wenn es nötig ist.

Danek euch, hat mir sehr geholfen.


[CENTER]

Okay, wohin kann ich die Rechnung schicken?

[/CENTER]

:p

nylen: Oh, jetzt verstehe ich, was du meinst.

Nun, kopieren tut sie dein eigenes Script/Programm, oder? Also ist das auch zuständig für die Fehlerüberprüfung.

Wenn die Backupplatte voll ist, sind die WAL Logfiles halt weg … PG sollte das im laufenden Betrieb nicht stören, aber bei einem Crash dürftest du in Probleme laufen.

ads schrob am 4898. September 1993:

Nun, kopieren tut sie dein eigenes Script/Programm, oder? Also
ist das auch zuständig für die Fehlerüberprüfung.

Wenn die Backupplatte voll ist, sind die WAL Logfiles halt weg

Negativ: Das archive_command muß laut Doku Fehler per exit status
anzeigen, worauf Postgres das Recyceln alter WAL-Dateien
einstellt.

… PG sollte das im laufenden Betrieb nicht stören, aber bei
einem Crash dürftest du in Probleme laufen.

Nachdem das Backup-Medium vollgelaufen ist, sammeln sich nun alte
WAL-Dateien in pg_xlog/ an. Ist dessen Platte ebenfalls voll,
lassen sich keine Transaktionen mehr comitten. Zu Datenverlust
sollte es also zu keiner Zeit kommen, ein fehlerfreies
Archivierungsskript vorrausgesetzt.

Gruß
Andreas

Entweder dein Parser oder dein Datum ist kaputt :smiley: :smiley: :smiley:

Wenn die Backupplatte voll ist, sind die WAL Logfiles halt weg

Negativ: Das archive_command muß laut Doku Fehler per exit status
anzeigen, worauf Postgres das Recyceln alter WAL-Dateien
einstellt.

Das setzt immer noch voraus, dass das Script diesen Fehler zurückmeldet. Was bei Unkenntnis nicht vorausgesetzt werden kann.

Aber Danke für den Hinweis.

Auch als praktisch Alteingesessener lernt man immer wieder etwas hinzu und ich wurde gerade über die Bedeutung dieses Datums aufgeklärt.

Dank an akretschmer.