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
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 arbeitet asynchron, von daher tritt das oben beschriebene Szenario nicht ein.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.
Ja, das ist darüber machbar.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).
PostgreSQL: Documentation: Manuals: PostgreSQL 8.3: Continuous Archiving and Point-In-Time Recovery (PITR)
Das sollte machbar sein. Selbst noch nie gemacht, aber bereits von anderen gehört, daß es funktioniert.Kann ich mittels Drbd (Pri/Sec-Server) eine Failoverlösung bauen, bei der maximal die offenen Transaktionen verloren gehen im Failoverfall?
Auf dem Wege nicht, aber z.B. via Slony wäre dies machbar. (Slony kann mit unterschiedlichen Versionen von PG arbeiten).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?
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.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.
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.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.
Andreas
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Nun, das 7er Buch wirf mal am besten Weg. Da stimmen bloss noch die Basics.
Das ist nicht das einzige nette Feature ;-)Und was soll ich sagen: Der Particial Index hat es mir angetan![]()
Ja.Trigger sind ja syncron und somit innerhalb der Transaction und somit ACID. Richtig?
Nein, Slony arbeitet mit einem zusätzlichen Daemon, der die Daten async weiter repliziert.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.
Vergleichbar ... sagen wir so: wenn du damit ein inkrementelles Backup oder eine Replikation baust, funktioniert das ganze - ohne Probleme wie hinterherhängende Slaves ect.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).
Damit werden inkrementelle Backups abgebildet, ja.
Ich habe auch eine funktionierende Replikation, die auf WAL-Logs aufbaut.
Ja, kostet aber Performance.Kann ich mittels Drbd (Pri/Sec-Server) eine Failoverlösung bauen, bei der maximal die offenen Transaktionen verloren gehen im Failoverfall?
Nicht so wirklich. Es gibt Arbeiten, um das Update in-place zu erledigen, das dauert aber noch ein bischen.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?
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.
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.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.
Hum, dafür sollte es aber einige Beispiele im Netz geben.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.
Nun ja, englisch ist auch hier die dominierende Sprache.Ich hab bis jetzt nichts deutschsprachiges und gutes gefunden.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Erstmal danke.Ihr hab erstmal meine vermutungen bestätigt
Da stimme ich dir voll zu. Aber wie bereit geschrieben kenne ich verdammt gut mit MySQL aus und kenne somit die schwächen und so ein Index vermisse ich gerade bei großen Datenmengen und daher hat er es mir einfach angetanZitat von ads
Aber nur wenn die Hardware nicht stimmt und die Datenbank eine extrem große Schreiblast hat. Also in dem Ex-Unternehmen habe ich da viel auf MySQL basis gemacht und ich muss sagen das es immer 100% war. Notfalls wenn es nicht um Sicherheit gehen würde (aber darum macht man das ja) könnte man eine anderes DRBD-Protocol verwenden das früher bestätigt und asnyc arbeitet.Zitat von ads
An sowas habe ich auch schon gedacht, aber ich dachte das geht nicht bzw weis nicht wie ich das machen soll, da ja slony laut Dokumentation die Daten vor slonystart bereits in der anderen DB erwartet.Zitat von ads
Jo das hab ich mir auch gedacht nachdem ich gelesen hatte das die Loggröße in Sourcecode stehtZitat von ads
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.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
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. ;-)
Vielleicht gibt es das für Debian auch. FAQ-Beitragsschreiber sind immer gerne willkommen. ;-)
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.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen