Re: Permanentbackup, alles ohne Unterbrechung des Betriebs

Hallo,

weiß jemand von euch, wie man mit Perl DBI, DBD::Pg das Encoding
bzw. den charset von Datenbanken feststellen kann?

Besten Dank!

Viele Grüße
Udo Spallek

am Wed, dem 27.06.2007, um 21:14:07 +0200 mailte udono folgendes:
> Hallo,
>
> weiß jemand von euch, wie man mit Perl DBI, DBD::Pg das Encoding
> bzw. den charset von Datenbanken feststellen kann?

Würde mich wundern, wenn das nicht mit "show client_encoding;" bzw.
"show server_encoding;" ginge.

Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

hi udo,

udono schrieb:
> Hallo,
>
> weiß jemand von euch, wie man mit Perl DBI, DBD::Pg das Encoding
> bzw. den charset von Datenbanken feststellen kann?
>
> Besten Dank!
>
> Viele Grüße
> Udo Spallek
>
>
z.b. so:

SELECT d.datname as "Name",
u.usename as "Owner",
pg_catalog.pg_encoding_to_char(d.encoding) as "Encoding"
FROM pg_catalog.pg_database d
LEFT JOIN pg_catalog.pg_user u ON d.datdba = u.usesysid
ORDER BY 1;

gruss
ralf

Guten Tag,

ich würde gerne mal euere Meinung dazu hören, ob es mit Postgres 8.2.x
schon machbar ist ein
vernünftiges Onlinebackuptool zu realisieren (z.B in dem man die Shell
Utillities sinnvoll
durch eine GUI parametrisiert).

Die Ausgangslage ist folgende:

Angemieteter ROOT-Server mit Debian Edge (aktuelles Patchlevel)
AMD64-Bit DUAL Core Opteron mit 2 GByte RAM Speicher, 1000 MBits
mehrfach Redundant
angebunden ans Inet. Auf der Maschine läuft nur PostgreSQL 8.2-64-Bit
ansonsten überhaupt nichts.

Vom Provider wird ein via FTP erreichbarer, interner FTP-Server angboten um
Backupfiles aller Art zu sichern (läuft über internes LAN des Providers
mit Glasfaserverkabelung
vom Rootserver zum internen Backupserver)

Meine PostgreSQL Installation:
- PostgreSQL 8.2.4-1 64-Bit Version, von Hand kompiliert und optimiert
läuft auf der Maschine
- Tablespaces sind wie folgt angelegt:
Tabelle: webapp.forum /var/pgdata/tblspace/forum
Tabelle: webapp.messages /var/pgdata/tblspace/messages
Tabelle: webapp.profiles /var/pgdata/tblspace/profiles

- Das ganze läuft recht zügig, es gibt viele 1 zu n Relationen
- Es werden viele SQL-Variablebindings benutzt.
- Der Webserver greift via Connectionpooler, von einer anderen Maschine
auf den DB-Server
zu um die DB-Server Ressourcen zu schonen.

Momentan sind ca. 600 GByte Gesammtdaten in allen Tablespaces vorhanden.

Mein Problem ist nun, das ich für ein Dump basiertes Backup die DB für die
User sperren müsste um die Daten sichern zu können, da dies aber bei 600
GByte
extrem lange dauern würde, möchte ich eher ein Onlinebackupverfahren
einrichten.

Ich stelle mir das in etwas so vor. Es wird ein ab einem gewissen
Zeitpunkt ein
komplettes Backup der ganzen Datenbank gezogen und fortan werden durch einen
Permanentbackupprozess nur noch die Änderungsdaten der Datenbank auf den
entfernten
FTP-Backupserver geschrieben als File geschrieben.

Die Vorteile aus meiner Sicht:
- Die ständigen Backupdaten sind relativ gering und können im Hintergrund
auf dem FTP-Backupspace im laufenden Betrieb gesichert werden

- Bei einem Maschinbencrash kann man faktisch auf ein sek. genaues
Backup zurückgreifen
und wieder einspielen.

Was meint Ihr? Bringt PG alles mit um sowas zu realisieren?

Das nächste Thema wäre natürlich ein Spiegel mit S-Lony mit ca. der
gleichen Hardware
wie der Primäre DB Rootserver, ebenfalls via internes LAN des Providers
mit Glasfaser verbunden, aber das ist ist ein anderes, komplexes Thema
wie ich denke

Naja,ich denke es ist klar geworden was ich beabsichtige, ich brauche
halt eine
Antwort ob sowas generell mit PG machbar ist und wenn ja, wer sich in
der Lage sieht sowas
zu programmieren.

Gruß Apoc

am Tue, dem 04.09.2007, um 14:21:58 +0200 mailte apoc9009 folgendes:
> Guten Tag,

BITTE KEINE FREMDEN THREADS ENTFÜHREN!

Also, nicht einfach eine Mail nehmen, darauf antworten, alles löschen
und das Betreff ändern. Solch eine Mail landet dennoch im falschen
Thread.

>
> ich würde gerne mal euere Meinung dazu hören, ob es mit Postgres 8.2.x
> schon machbar ist ein
> vernünftiges Onlinebackuptool zu realisieren (z.B in dem man die Shell

Ja, das geht schon vor 8.2

> Utillities sinnvoll
> durch eine GUI parametrisiert).

Ohne Shell und GUI. Einfach das WAL wegsichern.

> Vom Provider wird ein via FTP erreichbarer, interner FTP-Server angboten um
> Backupfiles aller Art zu sichern (läuft über internes LAN des Providers

Geht auch SCP?

> Momentan sind ca. 600 GByte Gesammtdaten in allen Tablespaces vorhanden.
>
> Mein Problem ist nun, das ich für ein Dump basiertes Backup die DB für die
> User sperren müsste um die Daten sichern zu können, da dies aber bei 600
> GByte
> extrem lange dauern würde, möchte ich eher ein Onlinebackupverfahren
> einrichten.

Verständlich.

>
> Ich stelle mir das in etwas so vor. Es wird ein ab einem gewissen
> Zeitpunkt ein
> komplettes Backup der ganzen Datenbank gezogen und fortan werden durch einen
> Permanentbackupprozess nur noch die Änderungsdaten der Datenbank auf den
> entfernten
> FTP-Backupserver geschrieben als File geschrieben.

Also sowas wie hier beschrieben:
http://www.postgresql.org/docs/8.1/interactive/backup-online.html

>
> Die Vorteile aus meiner Sicht:
> - Die ständigen Backupdaten sind relativ gering und können im Hintergrund
> auf dem FTP-Backupspace im laufenden Betrieb gesichert werden

Dazu dient archive_command in der postgresql.conf. Das sollte auch mit
FTP machbar sein, SCP ist mir persönlich angenehmer.

> Was meint Ihr? Bringt PG alles mit um sowas zu realisieren?

Ja.

Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

apoc9009 schrieb:
> ich würde gerne mal euere Meinung dazu hören, ob es mit
> Postgres 8.2.x schon machbar ist ein vernünftiges
> Onlinebackuptool zu realisieren (z.B in dem man
> die Shell Utillities sinnvoll durch eine GUI parametrisiert).
>
> Momentan sind ca. 600 GByte Gesammtdaten in allen Tablespaces
> vorhanden.
>
> Mein Problem ist nun, das ich für ein Dump basiertes Backup
> die DB für die User sperren müsste um die Daten sichern zu
> können, da dies aber bei 600 GByte extrem lange dauern würde,
> möchte ich eher ein Onlinebackupverfahren einrichten.

Dump, ist das dump(8)?

Bei einem Online-Backup einer PostgreSQL-Datenbank muß man die
User nicht aussperren, auch keine Locks auf Tabellen legen etc.

Man sagt pg_start_backup(text), sichert die Datenbank-Files
mit einem Werkzeug seiner Wahl, und sagt dann pg_stop_backup().
Ob das jetzt tar oder dump oder sonstwas ist, ist egal.

600 GB sind natürlich nicht klein, da dauert ein volles Backup
schon einige Zeit...

Alternativ kann man auch die Daten mit pg_dump exportieren,
das kann auch als Backup verwendet werden.

> Ich stelle mir das in etwas so vor. Es wird ein ab einem gewissen
> Zeitpunkt ein komplettes Backup der ganzen Datenbank gezogen
> und fortan werden durch einen Permanentbackupprozess nur noch
> die Änderungsdaten der Datenbank auf den entfernten
> FTP-Backupserver geschrieben als File geschrieben.

Inkrementelle Backups gibt es bei PostgreSQL leider nicht.

> Das nächste Thema wäre natürlich ein Spiegel mit S-Lony mit ca. der
> gleichen Hardware wie der Primäre DB Rootserver

Das ist natürlich auch möglich und kann bei einem Ausfall der
Datenbank helfen.

Es ist aber natürlich kein Backup - was ist, wenn man wegen eines
Problems auf den Stand von heute Mitternacht zurückgehen muß
(z.B. weil irgendjemand versehentlich Daten gelöscht hat)?
Dann hilft ein Spiegel gar nichts.

Liebe Grüße,
Laurenz Albe

Am Dienstag, 4. September 2007 14:21 schrieb apoc9009:
> Mein Problem ist nun, das ich für ein Dump basiertes Backup die DB für die
> User sperren müsste um die Daten sichern zu können

Das halte ich aber für einen Irrtum.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

> 600 GB sind natürlich nicht klein, da dauert ein volles Backup
> schon einige Zeit...
>
Das ist genau der Punkt um den es mir geht. Es ist schon problematisch,
das zwischen
Backup Start und Backup Stop eine Sicherungslücke existiert. Es muss
wirklich so sein,
das jederzeit ein exaktes 1:1 Backup des aktuellen IstZustand der
Datenbank verfügbar ist
und bei Bedarf ohne irgendwelche experimente sicher zurück geschrieben
werden kann.

Das es prizipiell geht, weß ich aus dem ORACLE Umfeld.
Für ORACLE gibt es z.B von EMCSoftware ein derartiges Permanentbackuptool,
das sie sich durch den Aufkauf von Legato unter den Nagel gerissen haben
(da sind ja
Datenbanken auch im Terrabytebereich keine Seltenheit und daher ist man
sich des
Problems scheinbar schon früher bewußt gewesen). Nur ORACLE ist halt
preislich
gesehen + Backupoption ein ordentlicher Brocken, den ich gerne vermeiden
möchte
wenn es irgend geht und lieber in Hardware investieren möchte.

Was gar nicht geht, ist das ich die Website stundenlang off schalte um
eine Häppchenweise
Datensicherung anzufertigen, ich möchte das der Betrieb überhaupt nicht
gestört wird und
trotzdem ein komplettes 1:1 Backup auf einem Hardwaremässig getrennten
Backupserver
hinterlegt ist, am liebsten 5 Sek. vor dem Crash genau.

> Inkrementelle Backups gibt es bei PostgreSQL leider nicht.
>
Wenn ich es nicht falsch verstanden habe, hat Andreas K angedeutet das
der Archive
Parameter in der postgresql.conf für etwas vergleichbares wie ein
inkrementelles Backup
nutzbar gemacht werden kann. Ich bin diesbezüglich aber gerade die Doku
am studieren
und vielleicht kann ich was brauchbares in dieser Hinsicht
zurechtbasteln, ich werde sicherlich
einige Tests laufen lassen, eventuell innerhalb einer VMWare Testumgebung.

> Es ist aber natürlich kein Backup - was ist, wenn man wegen eines
> Problems auf den Stand von heute Mitternacht zurückgehen muß
> (z.B. weil irgendjemand versehentlich Daten gelöscht hat)?
> Dann hilft ein Spiegel gar nichts.
>
Hmm, ich glaube da hätte ich auch bei meinem Permanentbackup ein
Problem, da es
ja immer den letzten, aktuellen Stand wiederspiegelt, es sei denn, es
existiert die
Möglichkeit verschiedene Sicherungsversionen (chronologisch sortiert)
zurück zu spielen.

Grüße Apoc

am Tue, dem 04.09.2007, um 15:50:13 +0200 mailte apoc9009 folgendes:
> >Inkrementelle Backups gibt es bei PostgreSQL leider nicht.
> >
> Wenn ich es nicht falsch verstanden habe, hat Andreas K angedeutet das
> der Archive
> Parameter in der postgresql.conf für etwas vergleichbares wie ein
> inkrementelles Backup
> nutzbar gemacht werden kann. Ich bin diesbezüglich aber gerade die Doku
> am studieren

Naja, man sichert sich einmalig den Stand und ab dann nur die
Veränderungen. Das sind dann jedesmal 16 MByte große Bröckchen.

IIRC kann man das aber wohl auch verkleinern. Was bleibt, ist, daß es da
halt immer eine gewisse Zeitspanne gibt, bis ein neues WAL-File fertig
ist und dieses archiviert werden kann.

>
> >Es ist aber natürlich kein Backup - was ist, wenn man wegen eines
> >Problems auf den Stand von heute Mitternacht zurückgehen muß
> >(z.B. weil irgendjemand versehentlich Daten gelöscht hat)?
> >Dann hilft ein Spiegel gar nichts.
> >
> Hmm, ich glaube da hätte ich auch bei meinem Permanentbackup ein
> Problem, da es
> ja immer den letzten, aktuellen Stand wiederspiegelt, es sei denn, es
> existiert die
> Möglichkeit verschiedene Sicherungsversionen (chronologisch sortiert)
> zurück zu spielen.

Das würde allerdings gehen, Point-in-time - Recovery.

Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

Hallo,

Am 04.09.2007 um 15:50 schrieb apoc9009:

Apoc? Wer das?

>> 600 GB sind natürlich nicht klein, da dauert ein volles Backup
>> schon einige Zeit...
>>
> Das ist genau der Punkt um den es mir geht. Es ist schon
> problematisch, das zwischen
> Backup Start und Backup Stop eine Sicherungslücke existiert.

Ich meine, dass dieser Punkt in der Doku ganz gut erläutert ist.
Andreas hat Dir den Pointer noch mal explizit aufgeschrieben.

Das Verfahren ist nicht trivial und ich habe mich für unsere
relativ kleine DB dagegen entschieden, dumpe nur einmal täglich,
was sehr flott geht bei mir. Der Punkt ist aber, daß alle Deine
Einwände in der Doku ausführlich behandelt werden. Wenn Du mit
den dort gegebenen Erklärungen nicht klar kommst, dann ist das
interessant für die Liste, weil wir dann lernen, wo die Doku
noch verbessert werden kann. Bei mir entsteht allerdings
der Eindruck, daß Du die Doku schlicht nicht gelesen hast
und darauf wartest, daß jemand sie hier für Dich paraphrasiert.
In diesem Fall ist eigenes Denken wirklich nicht hilfreich,
nimm lieber mal eine mentale Infusion aus der Doku entgegen.
Dort steht, was ein W(rite)A(head)L(og) genau ist, wie man es
benutzen kann, um Transaktionen zu replayen und daß Backup
Start und Stop nichts starten und stoppen sondern Marker sind,
die genau dazu dienen, daß dazwischen nichts verloren geht.
Mist, jetzt habe ich mich doch dazu benutzen lassen.
Fühlt sich nicht gut an. Ist sonst netter hier.

Gruß, Christian

http://burger-ag.de/postgresql_replikation.whtml
http://www.pro-linux.de/berichte/postgresql-daten-sichern.html#ToC6

A. Kretschmer schrieb:
> am Tue, dem 04.09.2007, um 15:50:13 +0200 mailte apoc9009 folgendes:
>
>>> Inkrementelle Backups gibt es bei PostgreSQL leider nicht.
>>>
>>>
>> Wenn ich es nicht falsch verstanden habe, hat Andreas K angedeutet das
>> der Archive
>> Parameter in der postgresql.conf für etwas vergleichbares wie ein
>> inkrementelles Backup
>> nutzbar gemacht werden kann. Ich bin diesbezüglich aber gerade die Doku
>> am studieren
>>
>
> Naja, man sichert sich einmalig den Stand und ab dann nur die
> Veränderungen. Das sind dann jedesmal 16 MByte große Bröckchen.
>
> IIRC kann man das aber wohl auch verkleinern. Was bleibt, ist, daß es da
> halt immer eine gewisse Zeitspanne gibt, bis ein neues WAL-File fertig
> ist und dieses archiviert werden kann.
Hmm ok, das grundsätzliche Prinzip ist klar,allerdings sind Datenbrocken
von 16 MByte doch
ziemlich unangenehm. Wie Du schon sagtest, die WAL's erstmal da sein,
damit man sie archivieren kann.

Wenn jetzt eine Desaster Situation auftritt, habe ich einen Verlust von
16 MByte, das bedeutet ein paar
hundert tausend Nachrichten der User sind weg /es geht ja nur um ASCII
Text) . Selbst wenn es nur 1 MByte ist,
ist das schon zu viel. Wenn ich das jetzt richtig verstehe, muss ich die
16 MByte auf die kleinste, mögliche Dateigröße
einstellen die geht, was wohl dann dazu führen wird das ich auf dem
Backupspace unüberschaubar viele, lose Archive haben
werde... Ich bin gerade am zweifeln ob ich es so hinbekomme ein
lückenloses Permanentbackup einzurichten mit
ca +- 5-10 Sek Tolleranz hinsichtlich Datenverlust..

Was meinst Du übrigens mit IIRC? Ist doch eigentlich ein Kürzel fürs
chatten im IRC Net oder nicht?

am Tue, dem 04.09.2007, um 20:15:37 +0200 mailte apoc9009 folgendes:
> >IIRC kann man das aber wohl auch verkleinern. Was bleibt, ist, daß es da
> >halt immer eine gewisse Zeitspanne gibt, bis ein neues WAL-File fertig
> >ist und dieses archiviert werden kann.
> Hmm ok, das grundsätzliche Prinzip ist klar,allerdings sind Datenbrocken
> von 16 MByte doch
> ziemlich unangenehm. Wie Du schon sagtest, die WAL's erstmal da sein,
> damit man sie archivieren kann.

Dann suchst Du Replikation. Hint: Slony.

> Was meinst Du übrigens mit IIRC? Ist doch eigentlich ein Kürzel fürs
> chatten im IRC Net oder nicht?

http://www.uwe-stoeckert.de/usenet/akronym.htm#akro_i

Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

> Dann suchst Du Replikation. Hint: Slony.
Danke!
Mit Slony hatte ich mich auch schon etwas befasst, allerdings ist das ja
nicht das selbe wie ein
vollwertiges Backup. Albe hat es ja schon angesprochen, wenn man den DB
Stand von dd.mm.yyyy.hh.mm.ss
zurückspielen muss, dann siehts düster aus.Es sollte also schon ein
vollwertiges Backup sein!

Was ich aber interressant finden würde, wäre die folgende Fragestellung:

Angenommen ich habe eine zweite Maschine mit identischer Konfiguration
und Parametrisierung wie die Master DB,
ist es dann Prinzipiell möglich von der replizierten Datenbank, auf dem
zweiten DB-Server das Onlinebackup aus
vorzunehemen?

Und wie viel Overhead verursacht Slony überhaupt? Mit wie viel
Performanceeinbruch muss ich rechnen
wenn ich das nutzen möchte?

Ich frage das deswegen, weil ich bei allem was ich mache die Last auf
die Haupt-DB so gering wie möglich halten will
und ziehe daher alle Register, vor allem bei den Queries (z.B makiere
ich bei Löschvorgängen die Datensätze nur
und führe Batch Löschjobs zu Zeiten mit geringer DB Aktivitäten durch
oder lasse mir via Explain immer genau
anzeigen in welchen Abschnitt meiner Queries noch Optimierungsbedarf
hinischtlich des Exekution Plan besteht)
Das hat bisher auch immer dazu geführt das ich nie wirkliche Performance
Schwierigkeiten mit PG hatte, das
sieht bei MySQL mit ISAM Tabellen leider schon ganz anders aus ;D

Apoc

apoc9009 schrieb:
> Angenommen ich habe eine zweite Maschine mit identischer
> Konfiguration und Parametrisierung wie die Master DB,
> ist es dann Prinzipiell möglich von der replizierten
> Datenbank, auf dem zweiten DB-Server das Onlinebackup aus
> vorzunehemen?

Ja, natürlich.

Ich würde trotzdem erwägen, ob nicht eine ganz normale
Online-Sicherung gut genug ist.

Ich würd's ausprobieren und schauen, ob es *wirklich* zu viel
Last auf dem I/O-System ist. Es wäre nämlich viel einfacher, und
das ist immer ein großer Vortail bei Dingen, die möglichst
automatisch laufen sollen.

> Ich frage das deswegen, weil ich bei allem was ich mache die Last auf
> die Haupt-DB so gering wie möglich halten will
> und ziehe daher alle Register, vor allem bei den Queries (z.B makiere
> ich bei Löschvorgängen die Datensätze nur
> und führe Batch Löschjobs zu Zeiten mit geringer DB Aktivitäten durch

Ich frage mich, ob das was bringt.
PostgreSQL macht es eh schon so: alte Datensätze werden erst bei
einem VACUUM aus der Datenbank gelöscht. Die Methode, Datensätze erst
zu markieren und erst in der Nacht zu löschen, verursacht eigentlich
einen Mehraufwand:

Beim Markieren des Blockes (ist wohl ein UPDATE) wird eine
neue Version des Datensatzes angelegt. Die alte wird unsichtbar.
Beim Löschen wird dann auch die neue Version unsichtbar.
Erst beim VACUUM werden beide Zeilen entfernt.

Wenn man die Zeilen gleich löscht, spart man sich die Hälfte
des Aufwandes. Das VACUUM muß man sowieso machen, das ist
dann der "Batch Löschjobs zu Zeiten mit geringer DB Aktivität".

Fazit: nicht ohne Grund das Rad neu erfinden.

Liebe Grüße,
Laurenz Albe

> Wenn man die Zeilen gleich löscht, spart man sich die Hälfte
> des Aufwandes. Das VACUUM muß man sowieso machen, das ist
> dann der "Batch Löschjobs zu Zeiten mit geringer DB Aktivität".
>
> Fazit: nicht ohne Grund das Rad neu erfinden.
>
> Liebe Grüße,
> Laurenz Albe

Danke für den Tip, das wusste ich natürlich nicht, werde es aber bald in
meine
Programmierung einbauen und mal gucken ob es so nicht besser funktioniert!