Replikation zu offline Server gesucht

Halllo,

ich habe einen Postgresql Server (v. 9.5.x) auf einem Windows Host laufen.

Nun möchte ich eine Replikation zu einem unter Linux laufenden Postgresql Server (auch v. 9.5.x) aufsetzen. Dieser soll als read-only Server separat verwendbar sein - auch wenn der Master-Server nicht erreichbar ist.

Da dieser an einem anderen Standort steht habe habe ich mir folgendes Szenario ausgedacht:

  • Linux-Server (Slave) verbindet sich (z.B. 1 mal pro Tag per VPN) zum Netz des Masters
  • Postgresql holt sich (per streaming replication ?) die Änderungen
  • Verbindung wird getrennt

Nun habe ich nach Lesen der Dokumentation den Eindruck daß alle Beschreibungen davon ausgehen, daß die Server immer gegenseitig erreichbar sein müssen, was im meinem Fall ja nicht der Fall ist. Z.B. ist in meinem Fall beim Start des Slaves das nie der Fall - er muß aber trotzdem im nur-Lesemodus verwendbar sein.

Wie geht man das am “dümmsten” an ?

Vielen Dank für die Hilfe.

Falls ich Dich soweit richtig verstanden habe geht das schon. Der ‘Slave’ muß mit einer passenden recovery.conf starten, und der Master muß die WAL’s lange genug aufheben, damit der Slave diese bekommen kann. Hier bieten sich Replication Slots absolut an. Das ganze hat naürlich einige Fallstricke:

  • der Slave ist wirklich nur Read Only
  • auf dem Master mußt Du aufpassen, daß der Platz durch die da umliegenden WAL’s nicht knapp wird
  • du wirst auf dem Slave Daten sehen, die möglicherweise schon lange auf dem Master gelöscht und, und Daten nicht sehen, die da schon lange da sind

TL;DR

So ein Setp ist nicht das, was man als schön bezeichnen würde. Aber machbar.


Grüße aus der schönen Toskana. Das schreibe ich jetzt extra für meinen Ex-Kollegen :wink:

Also eine Replikation bei der sich manchmal für längere Zeit die Server nicht sehen ist schon eher suboptimal, aber natürlich machbar.
Wenn deine Platte auf dem Windows-Server groß genug ist, solltest du am ehesten zu Replication-Slots greifen. Hat den Vorteil, das hier die WAL-Files für die Slaves aufgehoben werden, bis diese wieder synchron sind. Nachteil ist der gleiche Satz nochmal :slight_smile:
Ohne Replication.Slots solltest du den maximalen Zeitraum kennen den sich die Server eventuell mal nicht sehen, 2 Stunden drauf legen und min. diese Zeit als WAL-Files behalten.

@akretschmer: Viel Spaß und richte Grüße aus :p

Danilo: du kannst die Anzahl der WAL’s definieren, die aufzuheben sind, nicht aber die Dauer. Insofern ist das nicht trivial machbar. Wenn im Workload mal mehr WAL’s anfallen als üblich UND/ODER das Lag zwischen den beiden größer ist ist halt die Replikation im Eimer. Der sicherste Weg sind hier wirklich Slots, mit dem genannten Risiko.

Eine andere Idee noch wäre der Einsatz von Barman. Da eine Replikation ja ein Backup nicht ersetzt (nicht ersetzen kann!), wäre das natürlich keine so schlechte Idee. Man braucht halt noch einen dedizierten Barman-Server - den man aber ohnhin haben sollte. Der Slave fragt nach dem Hochkommen den Barman nach WAL’s ab, und wenn er diese hat, schaltet er auf SR vom Master um.

Danilo: ich glaube, die kennen dich hier nicht …

akretschmer: Mir ist schon klar, das man da keine Zeit angeben kann. Aber man kann ja über die Zeit beobachten wie viel da im Durchschnitt anfällt und das dann auf die ggf. Ausfallzeit+Puffer hochrechnen, falls das mit den Slots zu kompliziert oder ggf. zu unsicher ist (Falls der Server wirklich mal bedeutend länger weg ist als geplant, läuft dem die Platte voll). Die schönere Lösung wären die Slots aber allemal.

Der Barman klingt interessant. Muß der im Netz des Masters stehen und immer aktiv sein oder kann der auch Remote aufgebaut werden (analog zum Slave mit regelmäßigem VPN-Login) ?

Die Idee hinter der ganzen Sache ist eine read-only Kopie des Masters zu haben, wobei die Aktualität der Daten nicht unbedingt maßgebend ist. Da dürfen auch mal Tage Abstand sein. Als HA-Lösung ist das nicht gedacht.

Auch ist das Datenaufkommen/-änderungen am Master eher gering.

Die Idee mit Barman ein Disaster-Backup zu haben hat was.

In den Requirements steht Linux + ssh connection. Zur Erinnerung der Master läuft unter Windows (kanns leider nicht ändern).
Ich werde mir das mal ansehen ob das auch mit einem Windows-Master zusammenspielt. Irgendwo ist mir die Info über den Weg gelaufen, daß Replikation Windows <–> Linux ein Problem ist.

Damn. Physical Replication geht in der Tat in diesem Szenario Win <–> Linux nicht. Und Barman benötigt SSH ziemlich zwingend. Das habe ich bis jetzt übersehen, daß hier Windows involviert ist.

Ansonsten wäre es nice to have, daß der Barman-Server immer erreichbar ist.

Was Dir nun bleibt sind:

  • logische Replikation via pg_logical, was aber noch sehr ‘frisch’ ist, und ich bin mir auch grad nicht sicher, ob das unter Windows verfügbar ist. Laut http://2ndquadrant.com/en/resources/pglogical/ wohl nicht.
  • eine der TRIGGER-basierten Replikationen, was aber nicht (mehr) wirklich zeitgemäß ist. Dies sind halt nicht oder weniger an das OS gebunden, allerdings scheint Londiste auch nicht unter Windows zu laufen, bleibt zumindest Slony.

TL;DR

Mit Windows hast halt die A-Karte gezogen. Vermutlich wäre der Aufwand, das zu ändern geringer, als eine Lösung dafür zu finden.

wie schaut das aus mit Cygwin auf Linux? Damit hättest du die wichtigsten Unix-Tools dabei (SSH,Rsync, usw.).
Aber ich hab das selbst noch nie versucht. Man könnte versuchen Postgres in der Cygwin-Umgebung laufen zu lassen und dann damit arbeiten.

Wenn das nix wird, bliebe noch die “Pseudo-Replikation” mit periodischen Dumps, welche auf den Slave kopiert und importiert werden. Da brauchst dir auch um Lags keine Sorgen mehr machen :wink:

Cygwin… lebt das noch? Aber irgend ein Linux, das virtualisiert auf dem Windows läuft. Man sollte aber wissen: virtuelle Hardware -> virtuelle Performance. Zumindest besteht die Gefahr …

Nunja, SSH daemons gibts für Windows auch.

Streaming Replication sollte doch kein Problem mit verschiedenen Betriebssystemen haben, oder ?

pg_basebackup  -h <host> -D <postgres-datadir> -U replicator -X stream -v -P

scheint ohne Fehler durchzulaufen. Den Slave habe ich allerdings noch nicht gestartet. Wie die postgresql.conf/recovery.conf dann aussehen muß damit der Slave ohne erreichbaren Master in den aktiven Modus (bereiit für Queries) geht muß ich erst nachlesen. Oder hat da jemand was fertiges ?

ja, das geht. Hab das eben mal mit meiner Spiel-VM probiert. Die recovery.conf:

standby_mode = 'on'
primary_conninfo = 'port=5432 host=pg95-slave user=repmgr application_name=erde'
recovery_target_timeline = 'latest'
primary_slot_name = repmgr_slot_1

Nicht über die Namen wundern, ich spiele mit repmgr rum und hab diverse Testinstanzen. Es läuft definitiv nur der Slave und er bedient lesende Abfragen.