Postgres und replikation

Hallo Leute,
ich bin recht frisch im Arbeiten mit Postgres. Ich habe schon ettliche Replikationen unter mysql aufgesetzt und muss zugeben ich war beim Einarbeiten in die Postgres Replikation geschockt.
Ich habe eine Replikation aufgesetzt via slony-I.
Dazu hätte ich noch einige Fragen:
Ich habe gelesen, das wenn es eine Schemaänderung in einer Table gibt, diese nicht automatisch repliziert wird, was natürlich einen sehr hohen administrativen Aufwand mit sich bringt. Gibt es dazu Ansätze oder gar Lösungen die man auch wirklich sicher einsetzen kann ?
Das weitere ist das Failover. Wenn ein Slave aus fällt, müsste ich laut angabe der Doc, einen aktuellen Dump einspielen und hoffen das in der Zeit keine neuen Einträge im Master eingepflegt werden( was im lifebetrieb immer Vorkommt) das hat zur Folge das eine Inkonsistenz der Daten absehbar ist.


Die Replikation an sich ist sehr einfach aufgebaut. Schreibzugriffe auf Master und Lesezugriffe (je nach Prio) auf Slave.
Also keine Multimaster Anwendung und noch nicht mal multi Slaves.

Gibt es einen sauberen Weg wie ich die oben genannten Probleme Lösen kann ? oder sind das evtl. keine Probleme, denn slonly kann das schon nur ich habs übersehen ?

Ich bin für jeden Tip Dankbar.

Grüße
Foexle

Natürlich. Slony-I

Das weitere ist das Failover. Wenn ein Slave aus fällt, müsste ich laut angabe der Doc, einen aktuellen Dump einspielen und hoffen das in der Zeit keine neuen Einträge im Master eingepflegt werden( was im lifebetrieb immer Vorkommt) das hat zur Folge das eine Inkonsistenz der Daten absehbar ist.


Die Replikation an sich ist sehr einfach aufgebaut. Schreibzugriffe auf Master und Lesezugriffe (je nach Prio) auf Slave.
Also keine Multimaster Anwendung und noch nicht mal multi Slaves.

Gibt es einen sauberen Weg wie ich die oben genannten Probleme Lösen kann ? oder sind das evtl. keine Probleme, denn slonly kann das schon nur ich habs übersehen ?

Ich bin für jeden Tip Dankbar.

Grüße
Foexle

Vielleicht wäre PITR bzw. WAL-Shipping eher eine Lösung für Dich. Im übrigen wird 8.5 eine integrierte Replikationslösung haben.


Andreas

Ok vielen dank das Hilft mir erst einmal weiter.
Das mit WAL-Shipping ist eigentlich genau das was mysql-repl auch macht. Das wäre schon mal ein Schritt in die richtige Richtung.

Dieses WAL, benutzt man das zusätzlich zu slony oder stattdessen ?
Denn ich denke wenn Slonly Statements absetzt zu den Nodes und dann die nodes noch über die Logfiles sich abgleichen werden die Datensätze nicht unbedingt konsistent bleiben, oder kommen die sich nicht in die quere?

Fragen über Fragen :slight_smile:

Nicht beides gleichzeitig.

Vereinfacht gesagt, mit dem Log-shipping hast Du den Slave im Cold-Standby, er verarbeitet die WAL-Logs, ist aber selber nicht in der Lage, Abfragen zu beantworten. 8.5 wird (wahrscheinlich) sogar einen Hot-Standby erlauben, also Du kannst auf dem Slave sogar Abfragen machen. Hot Standby - PostgreSQL Wiki

Andreas

ok also keine zugriffe auf die slave ist natürlich nicht das wahre vom ei … dann würde ich die master noch mehr belasten mit irgendwelchen select statements und was dann noch schlimmer währe das die IO Last auf dem Master sehr hoch währe und der Slave nix zu tun hat

Also ist wal evtl doch keine so gute alternative … :frowning:

Möchtest du eine Standby Maschine, nimmst du Log-Shipping. Das funktioniert im übrigen bei PostgreSQL sogar richtig. Für MySQL darfst du dich mal durch deren Bugtracker wühlen, was alles nicht in den Logdateien auftaucht und vieviele Bugmeldungen es über die Jahre gab. Verlassen würde ich mich darauf also nicht.

Möchtest du beide Maschinen parallel befragen können, nimmst du Slony. Für Änderungen an der Tabellenstruktur replizierst du die entsprechenden Anweisungen ebenfalls mittels Slony (das hat ein extra Feature dafür) und kannst dir sicher sein, dass die Änderungen auf jedem Slave zum richtigen Zeitpunkt eingespielt werden - nämlich parallel zu den Daten.

Das Befüllen der Tabellen eines Slaves erledigt Slony allein, darum brauchst du dich nicht zu kümmern. Allerdings muss bei einem Neustart der Replikation natürlich erst mal das gesamte Datenset übertragen werden - das kann etwas dauern, das stimmt.

Zusätzlich kann man eine Pooling-Lösung wie pgBouncer vor die Slony-Instanzen schalten und bekommt so einen schön verteilten Lastzugriff.


Generell bietet PostgreSQL für fast jeden Zweck gute Replikationslösungen, sie sind (bisher) nur nicht integriert. Das wird sich mit 8.5 auch ändern, die Leute sind faul und wollen alle nur einen Schalter umlegen :wink:

Also ich habe das ganze nun mal ausgetestet und läuft auch soweit alles. Bin eigentlich zufrieden … der Failover funktioniert auch. Allerdings was immer noch nicht so richtig will, bzw finde ich auch keinen Lösungsansatz, die Schemaänderung in tabellen. Das Script geht natürlich, aber ich benötige dies automatisiert und genau da liegt das Problem.

Man kann auch automatisiert Skripts erstellen - mache ich ständig.

An diversen Projekten, an denen ich mitarbeite, müssen Updates auf mindestens eine Devel und eine Live DB verteilt werden. Das geht nur, wenn man das automatisiert.

auch alter-scripte? womit und woraus erstellst du die? gibt es (gescheite) tools? oder funktionen die ich nicht kenne?

bisher hies es immer “selber machen” … aber man weiss ja nie …

bei pg koennte man sich sogar vorstellen (theoretisch) die aenderungen am Modell per WAL zu verteilen?! sind doch auch “nur” transaktionen … hast du dazu ideen?

Bitte differenziere zwischen WAL-Shipping und Lösungen wie Slony. Falls Dein französisch hinreichend gut ist: Freitag, 6. November, 13:50 Uhr Paris Schedule [European PGDay 2009] .

Andreas

ich sagte auch THEORETISCH … ich wollte wissen, ob sowas denkbar waere … mein gedanke war, dass solche alters ja transaktionen sind …

uff … französisch … ich war nur in der bretagne - da spricht man bretonisch :slight_smile:

und ja - ich habe mit slony noch nicht gerabeitet … replikation schoen und gut … die frage ist doch aber - was soll die replikation bewirken … und da findet sich irgendwie wenig darueber, wofuer slony besonders geeignet ist und was man damit besser nicht erreichen will … es soll ja fuer bestimmte anwendungsfaelle ne recht robuste sache sein … aber welche?

und robust kann auch viel heissen - was darf man erwarten - was nicht?

Seite 397ff. Im Buch von ads.


@ads: wir müssen noch mal über die Provision verhandeln.


Andreas

ist da was drann?
oder haben die einfach nur mist gebaut?
Campus IT » Blog

ach … mutiert das forum jetzt zur vertriebsplattform fuer ads?

na dann …

Vermutlich.

Der Satz:

Durch das WAL-Prinzip wird ein sogenanntes "Update-in-Place" ermöglicht, d.h. die alte Version eines Datensatzes wird durch die neue Version an gleicher Stelle überschrieben.

reicht eigentlich, um zu wissen, daß man da nicht weiterlesen braucht.

Der Satz:

Der WAL-Manager an sich ist ein in Phyton geschriebenes Script, welches die WAL-Logs aus der Master Datenbank abholt und diese auf der Gegenseiten (dem Slave) wieder in die Datenbank einspielt.

heißt übersetzt: wir haben archive_command nicht verstanden.

Andreas

In Paris. beim Abendessen :wink:


Nein. Aber da die Antwort dort offensichtlich schon mal drin steht, wird die Frage schon mal jemand gestellt haben.

Die haben HOT und WAL komplett verwechselt.
Das gesamte Posting enthält viel zu viele Fehler.

Dann ist ja gut … da werde ich gleich mal nach “Frage die schon mal jemand gestellt hat” suchen :wink:

Mach das. Mögest du Erleuchtung finden.