Paar Einsteigerfragen

Hallo erstmal


ich bin neu und nachdem ich nun seit 1 Woche nicht anderes machen als lesen (PGBuch 7er Reihe PDF, Changelogs der 8er Reihe, hier im Forum) und auch bei google) wäre ich dankbar über paar Infos.


Zurzeit verwende ich eine 5 virtuelle Testmaschinen mit pgsql8.3 und ubuntu 8.04 lts server.
Selbst bin ich MySQL Profi und habe bereits mit Datenbank in Terabytebereich gearbeitet.
Nun will ich meinen Horizont erweitern und da ja alles sagen PG soll so gut sein hab ich mit dem PGBuch angefangen. Und was soll ich sagen: Der Particial Index hat es mir angetan :smiley:


Nun gut:


Trigger sind ja syncron und somit innerhalb der Transaction und somit ACID. Richtig?


Slony basiert ja auf Trigger heißt das, dass ein Schreibzugriff erst bestätigt wird wenn alle Slaves die Änderung ebenfalls erfolgreich verarbeitet hat? Und was passiert wenn eines der Salves nicht mehr da ist, dann müsste ja der Trigger failen und somit ab dann bei jedem write direkt wieder ein Rollback machen.


Dann zur WAL-Datei. Ist die Vergleichbar mit der Binlog von MySQL? Wäre darüber ein Replikation möglich wie bei MySQL. Hab bereits paar ähnliche PG-Lösungen gefunden aber alle mit Einschränkungen. Wäre darüber ein Inkrementelles Backup möglich (siehe unten).


Kann ich mittels Drbd (Pri/Sec-Server) eine Failoverlösung bauen, bei der maximal die offenen Transaktionen verloren gehen im Failoverfall?


Was passiert mit Datenbeständen größer als 100GB oder gar über 500GB und einem Versionswechsel. Ist ein schneller Transfer mittels pg_dump überhaupt möglich?


Gibt es Möglichkeiten inkrementelle Backups zu machen, denn dann könnte ich Anfangen zu restoren in eine neue Version und würde dann nur noch inkrementelle Backups einspielen. So könnte ich eine Downtime in der Zukunft klein halten.


Und zu guter Letzt. Laut changelog gibt es nun tssearch direkt in 8.3 hat jemand damit schon Erfahrung sammeln können oder kennt einer ein schön Beispiel mit Tabelle und Beispiel SELECTs, wo man sehen kann wie die Daten indeziert und mittels tsquery abgefragt werden.


Und dann schonmal danke für das Forum scheint die einzige brauchbare Anlaufstelle zu sein laut Google. Ich hab bis jetzt nichts deutschsprachiges und gutes gefunden.

Ja.

Slony basiert ja auf Trigger heißt das, dass ein Schreibzugriff erst bestätigt wird wenn alle Slaves die Änderung ebenfalls erfolgreich verarbeitet hat? Und was passiert wenn eines der Salves nicht mehr da ist, dann müsste ja der Trigger failen und somit ab dann bei jedem write direkt wieder ein Rollback machen.

Slony arbeitet asynchron, von daher tritt das oben beschriebene Szenario nicht ein.

Dann zur WAL-Datei. Ist die Vergleichbar mit der Binlog von MySQL? Wäre darüber ein Replikation möglich wie bei MySQL. Hab bereits paar ähnliche PG-Lösungen gefunden aber alle mit Einschränkungen. Wäre darüber ein Inkrementelles Backup möglich (siehe unten).

Ja, das ist darüber machbar.
PostgreSQL: Documentation: Manuals: PostgreSQL 8.3: Continuous Archiving and Point-In-Time Recovery (PITR)

Kann ich mittels Drbd (Pri/Sec-Server) eine Failoverlösung bauen, bei der maximal die offenen Transaktionen verloren gehen im Failoverfall?

Das sollte machbar sein. Selbst noch nie gemacht, aber bereits von anderen gehört, daß es funktioniert.

Was passiert mit Datenbeständen größer als 100GB oder gar über 500GB und einem Versionswechsel. Ist ein schneller Transfer mittels pg_dump überhaupt möglich?

Auf dem Wege nicht, aber z.B. via Slony wäre dies machbar. (Slony kann mit unterschiedlichen Versionen von PG arbeiten).

Gibt es Möglichkeiten inkrementelle Backups zu machen, denn dann könnte ich Anfangen zu restoren in eine neue Version und würde dann nur noch inkrementelle Backups einspielen. So könnte ich eine Downtime in der Zukunft klein halten.

Die WAL-Files kannst Du IMHO nicht zwischen unterschiedlichen Versionen einsetzen. Du könntest aber Slony nehmen, allerdings kann das nicht incrementel so arbeiten, wie Du Dir das vorstellst.

Und zu guter Letzt. Laut changelog gibt es nun tssearch direkt in 8.3 hat jemand damit schon Erfahrung sammeln können oder kennt einer ein schön Beispiel mit Tabelle und Beispiel SELECTs, wo man sehen kann wie die Daten indeziert und mittels tsquery abgefragt werden.

Muß ich passen, sorry. Ich hab mal irgendwo die Frage gelesen, was denn der Unterschied zwischen dem MySQL-Fulltext und dem PG-Fulltext ist. Die Antwort war sinngemäß, daß das unter MySQL wohl alles viel einfacher sei, allerdings unter PG deutlich leistungsfähiger und flexibler. Ich selbst habe damit aber noch nicht gespielt.


Andreas

Nun, das 7er Buch wirf mal am besten Weg. Da stimmen bloss noch die Basics.


Und was soll ich sagen: Der Particial Index hat es mir angetan > :smiley: >

Das ist nicht das einzige nette Feature :wink:


Trigger sind ja syncron und somit innerhalb der Transaction und somit ACID. Richtig?

Ja.


Slony basiert ja auf Trigger heißt das, dass ein Schreibzugriff erst bestätigt wird wenn alle Slaves die Änderung ebenfalls erfolgreich verarbeitet hat? Und was passiert wenn eines der Salves nicht mehr da ist, dann müsste ja der Trigger failen und somit ab dann bei jedem write direkt wieder ein Rollback machen.

Nein, Slony arbeitet mit einem zusätzlichen Daemon, der die Daten async weiter repliziert.


Dann zur WAL-Datei. Ist die Vergleichbar mit der Binlog von MySQL? Wäre darüber ein Replikation möglich wie bei MySQL. Hab bereits paar ähnliche PG-Lösungen gefunden aber alle mit Einschränkungen. Wäre darüber ein Inkrementelles Backup möglich (siehe unten).

Vergleichbar … sagen wir so: wenn du damit ein inkrementelles Backup oder eine Replikation baust, funktioniert das ganze - ohne Probleme wie hinterherhängende Slaves ect.

Damit werden inkrementelle Backups abgebildet, ja.
Ich habe auch eine funktionierende Replikation, die auf WAL-Logs aufbaut.


Kann ich mittels Drbd (Pri/Sec-Server) eine Failoverlösung bauen, bei der maximal die offenen Transaktionen verloren gehen im Failoverfall?

Ja, kostet aber Performance.


Was passiert mit Datenbeständen größer als 100GB oder gar über 500GB und einem Versionswechsel. Ist ein schneller Transfer mittels pg_dump überhaupt möglich?

Nicht so wirklich. Es gibt Arbeiten, um das Update in-place zu erledigen, das dauert aber noch ein bischen.
Eine oft gewählte Möglichkeit ist ein Update mittels Slony, die eine DB fährt 8.2, die andere 8.3 und schon klappt das ganze. Ausfallzeiten im besten Fall im Sekundenbereich.


Gibt es Möglichkeiten inkrementelle Backups zu machen, denn dann könnte ich Anfangen zu restoren in eine neue Version und würde dann nur noch inkrementelle Backups einspielen.

Das inkrementelle Backup muss in die gleiche PG-Version wieder eingespielt werden. Zusätzlich müssen sogar die Rahmenbedingungen gleich sein: Endianess muss stimmen, wichtige Compile-Optionen müssen gleich sein, ect.


Und zu guter Letzt. Laut changelog gibt es nun tssearch direkt in 8.3 hat jemand damit schon Erfahrung sammeln können oder kennt einer ein schön Beispiel mit Tabelle und Beispiel SELECTs, wo man sehen kann wie die Daten indeziert und mittels tsquery abgefragt werden.

Hum, dafür sollte es aber einige Beispiele im Netz geben.


Ich hab bis jetzt nichts deutschsprachiges und gutes gefunden.

Nun ja, englisch ist auch hier die dominierende Sprache.

Und ein sehr gutes Forum reicht doch oder nicht? Wieso zig Seiten/Foren. :wink:

cu tb

Erstmal danke.Ihr hab erstmal meine vermutungen bestätigt :smiley:

Jo das hab ich mir auch gedacht nachdem ich gelesen hatte das die Loggröße in Sourcecode steht :smiley:

So erstmal danke dann bin ich ja froh das ich das meiste richtig verstanden habe. Ich frage lieber nach um nicht von falschen Tatsachen aus zu gehen.

Und noch ein Frage, verlässt sich jemand die Debianpakete bzw Distributionspakete? Oder kompiliert immer eure Versionen. Hab zwar gesehen, dass die scheinbar im Paketnamen die Mainversionsnummer integriert haben, aber was ist mit dem patchlevel bei sicherheits updates etc, gibt es da auch probleme mit der WAL bei einem Restore.
Möchte halt gerne wissen was passiert bevor der ernstfall eintritt ;D

Debian aktualisiert nur Bugfixes, dabei kannst du getrost das neue Paket über das alte installieren, die Binärdaten ändern sich dabei nicht.

Ich verwende CentOS - inzwischen aber nicht mehr die mitgelieferten RPMs sondern die, die ich direkt vom PostgreSQL-Server bekomme (siehe FAQ Beitrag dazu). Dadurch bin ich immer etwas aktueller. :wink:

Vielleicht gibt es das für Debian auch. FAQ-Beitragsschreiber sind immer gerne willkommen. :wink:

cu tb

Bleibt nur noch die offene Frage bzgl. Slony. und dem Versionsupgrade.
Oder kann jetzt Slony in neuen Version die Tabellen kopieren?
Vorallem wie nehme ich neue Slaves dazu bzw weg ohne ein pg_dump machen was ja bei 500GB nicht ohne wäre.

Man startet eine alte und eine neue DB jeweils mit Slony. Das Slony kopiert dann die Daten von der alten in die neue, während diese normal weiter läuft. Danach hat man zwei gleiche DBs und kann die alte abschalten.

Das dauert auch seine Zeit, aber das Kopieren/Updaten kann parallel zum normalen Betrieb erfolgen.

Also in den Dokumentationen die ich bis jetzt gefunden habe, steht über all man muss erst mittels pg_dump die Daten kopieren und danach die trigger aktivieren. Also ist das jetzt anders?! Perfekt dann erübrigen sich ja alle anderen Fragen :smiley: Super danke!

Jetzt muss ich mal ein DemoCluster aufsetzten.

Bei Slony? Kannst Du mir bitte einen (inWorten: einen) Link zeigen, wo das so steht?

Andreas

Also ich war mir sicher, dass ich das gelesen habe. Leider finde ich den englischen Beitrag nicht mehr. Aber was solls. Ihr macht das schön länger als ich, also muss ich was missverstanden haben. Englisch ist halt nicht meine Muttersprache :smiley:

Werd jetzt mal versuchen einen Slony-Cluster aufzusetzen…