Slony mit pgAdmin3

Hey Leute,
aktuell versuche ich eine Database auf meinen vernetzten PCs mit Windows 7 zu replizieren.
Da bin ich über Slony gestolpert. Mit dem Stackbuilder habe ich für meine Version 9.4 die Slony version 2.2.6 installiert.

Leider meldet mir pgAdmin, dass die Slony Skripte fehlen. Diese finden sich unter PostgreSQL\9.4\share wieder. Das habe ich auch in den pgAdmin Einstellungen für den Slony Pfad angegeben. Es sind insgesamt 6 an der Zahl. Wie z. B. slony1_base.2.2.6.sql, slony1_base.83.2.2.6.sql etc.

Ich hoffe ihr könnt mir helfen, da ich auch ansonsten Online zwar Leute mit dem gleichen Problem gefunden habe, aber ohne Ansatz zur Lösung des Problems.

Warum willst Du auf Slony setzen?

Slony wurde in Zeiten entwickelt, als PostgreSQL noch keine eingebaute Replikation hatte. Wenn Du Slony einsetzen willst, weil nur eine Teilmenge zu replizieren ist, dann würde ich Dir eher logical Replication empfehlen.

Ach ja: Du hängst auf einer relativ alten Version von PG.

Ja, ich weiß dass es mittlerweile die Version 10.2 gibt. Aber die Migration zu einer neueren Version steht noch aus.
Genau, das Problem ist, dass ich zwei Datenbanken in pg habe und nur eine davon möchte ich repliziert haben. Das andere Problem ist, ich bin auf Windows unterwegs :stuck_out_tongue: und da gibt es leider nicht so viele Möglichkeiten. Da alles Unix basiert ist. Meinst du mit logical Replication das pg_logical von 2nd Quadrant? Das ist ja nur mit Unix Systemen kompatibel, oder?

Ja, das pg_logical von 2ndQ meinte ich (ich arbeite bei 2ndQ)

Ja, mit Windows hast halt a bissl die Arschkarte gezogen, das schränkt halt alles ein. Wäre ich Du, würde ich Windows gegen z.B. CentOS tauschen und auf die 10er gehen.

Ja das würde ich auch gerne machen, aber leider darf ich das nicht :stuck_out_tongue:

Ich habe gerade mal bissl recherchiert und anscheinend wird MS Windows ab Version 2.1 supported. Aber leider nur vom SourceCode. Gibt es da eine Anleitung von euch, wie ich das anbinden könnte?

soweit ich weiß geht das nur mit Linux (Redhat-based oder Debian-based). Wo hast Du gelesen, daß das unter Windows geht?

Da habe ich oben den Link reingepostet. Dort steht das MS Windows supported wird, aber nur beim builden vom SourceCode

hehe, sehe ich auch so.

Hmmm… okay, müsste dann mal erst evaluieren was es rechtfertigt auf die Version 10 zu migrieren. Neben der Replikation.

  • Parallel Query
  • verbesserte Unterstützung für foreign tables (unter Umständen braucht ihr dann gar keine Replikation mehr)
  • Deklarative Partitionierung
  • viele andere Performance Optimierungen

andere Dinge wie z.B.:

  • parallel uery execution
  • definierbare statistiken über mehrere Spalten
  • wesentlich verbesserte Partitionierung
  • ICU collation support

außerdem seit 9.6:

  • parallel query
  • frozen data page in visibility map

und seit 9.5:

  • Row level security
  • BRIN indexe
  • insert on conflict
  • skip locked


    Das sind nur wenige der Features, da gibt es mehr.

Alles klar, danke Leute!

you are welcome

Ah vielleicht noch eine Frage. Mit der replication Funktion in postgresql 10, kann ich da ein master-master circle machen? D. h. alle sind master und es müssen alle Änderungen überall draufgespielt werden. Noch zusätzlich, dass nur eine DB auf dem Server dieses clustering hat und nicht alle.

Nein, master-master geht nicht, aber eine foreign table könnte dir dabei helfen. Da werden die Daten nur auf einem Server gespeichert alle anderen haben eine lokale “proxy” tabelle über die der Zugriff auf den eigentlichen Server geregelt wird.

Falls Du Master-Master suchst, wäre BDR das Stichwort. BDR 1 ist frei verfügbar, BDR 2 erfordert einen Supportvertrag mit uns, BDR 3 ist in Entwicklung.

Ach so, ja das Ding ist. Ich brauch eine Benutzer DB, die identisch auf allen anderen System im Netzwerk läuft.
Neben der Benutzer DB habe ich noch eine andere DB laufen, welche nicht repliziert werden darf.
Hab mich da auch mal reingelesen. Aber relationale DB Modelle bringen keinen von mir benötigten Master-Master Support. Was es meist gibt, ist halt ein Master-Master Circle. D.h. Node1 ist Master von Node2 und Node2 ist Master von Node3, Node3 ist Master von Node4 und Node4 ist Master von Node1. Fällt aber mal das Node3 weg, ist die Kette unterbrochen und die Datenbanken können nicht mehr synchronisiert werden.

Eine shared foreign table kann ich nicht machen, weil wir nicht zu 100% sagen können, dass ein System immer am Stromnetz hängt. Was ein zentrales System ausschließt.

Zu 2ndquadrant, der BDR Lösung, da muss ich mal schauen ob es auch auf Windows Systemen läuft.

Zu dem Thema Migration auf eine neuer Version von PG, ja wir werden auf 10 migrieren.