[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT]Re: Backup von einer postgreSQL mit 80 GByte?



Hallo, Marc!

Am Son, 2003-02-02 um 15.24 schrieb Marc F. Neininger:
> Am Fre, 2003-01-31 um 01.39 schrieb Michelle Konzack:
> Hallo Michelle,
> hallo Liste,
> 
> > Hmmm, ich denke, das _modifiziert_ sofort beim auslesen geleert 
> > werden muss, denn wenn ich danach mit pg_dump die liste abarbeite, 
> > rennt die postgresql ja weiter und weitere Tabellen koennten 
> > modifiziert werden. 
> 
> Das Backup-Konzept wirkt langsam ziemlich clever. Ich gebe nur zu
> bedenken, dass laut Murphy genau _nach_ dem Leeren von _modifiziert_
> Dein Computer hängenbleiben wird. Also würde ich _modifiziert_ nicht
> leeren, sondern umbenennen und für neue Einträge neu anlegen. Dann
> kannst Du pg_dump in aller Ruhe auf das alte _modifiziert_ loslassen.
[...]

Wenn das Skript, dass _modifiziert_ ausliest, abgearbeitet ist, sollten
die Daten in einer Datei stehen. Erst dann kann die Tabelle geleert
werden.
Sollte die Kiste beim Auslesen abstürzen, geht's nach dem Neustart mit
der unveränderten Tabelle von vorn los (Fall 1); nach dem Auslesen sind
die Daten in der Datei fixiert, dann interessiert der Tabelleninhalt für
diese Sicherung nicht mehr (Fall 2).
Sollte Michelle vermeiden, dass im zweiten Fall u.U. neue Einträge in
die Tabelle gelangen, bevor sie gelöscht wird?
Na ja: Eine Tabelle, die vor dem Absturz modifiziert wurde, würde
nochmal gesichert. Wenn sie nach dem Absturz nicht mehr verändert wird,
kommt sie nochmal ins Backup, was nicht schadet, sondern nur Platz
wegnimmt. Wird sie verändert, vermerkt das Skript sie ohnehin als zu
sichernd.
Das heisst: Nach 'nem Absturz kann sie so bleiben, wie sie ist - Leeren
erst bei der nächsten Sicherung.
Hab' ich was übersehen?
Mir scheint, als ob eine Tabelle reicht.

Noch 'ne Bemerkung zur Cleverness: Ich halte das Verfahren für ziemlich
umständlich.
Besser wär's, stattdessen mit Funktionen zu arbeiten (das kann
PostgreSQL). Es gibt ausserdem in PostgreSQL die Möglichkeit, Ereignisse
mit NOTIFY und LISTEN zu überwachen (wenn die Tabelle xyz verändert
wird, bekommt der LISTENER automatisch eine Nachricht).
Und schliesslich bietet PostgreSQL Transaktionen an - damit lassen sich
die Eventualitäten beim Rechnerbetrieb ganz gut regulieren.
Ich denke, dass PostgreSQL so zu betreiben ist, dass auch das Backup vom
Datenbanksystem selbst erledigt wird.
Aber: Die Datenbank läuft bei Michelle schon; ob es möglich ist, sie so
umzubauen, dass der Workaround nicht gebraucht wird, kann ich nicht
beurteilen, deswegen habe ich nichts anderes vorgeschlagen.
(Nicht als Rüffel verstehen, Marc!)

Gruss

Peter



Reply to: