Re: PostgreSQL Cluster

Moin,

Am 10.05.2018 um 11:11 schrieb Andreas Kretschmer:
> On 10 May 2018 10:27:51 CEST, Michael Post <michael_post(at)web(dot)de> wrote:
>> Hallo,
>>
>> ich versuche einen PostgreSQL-Cluster mit aktuell zwei Nodes
>> aufzubauen.
>> Ziel ist es, eine ausfallsichere Umgebung aufzubauen, so dass
>> theoretisch jederzeit ein Node wegbrechen kann und die Umgebung dennoch
>> korrekt weiterläuft (auch ohne Eingriff eines Administrators).
>> Gleichzeitig ist ein Loadbalancing über alle verfügbare Nodes
>> gewünscht.
>>
>> Ich habe mich mit pgpool2 beschäftigt. Aber irgendwie ist mir das
>> Prinzip noch nicht ganz klar, wie die Nodes synchron gehalten werden
>> und
>> wie ein zuvor weggebrochender Node wieder mit dem vorher existierenden
>> Node synchronisiert wird (evtl. automatisch?).
>>
>> Ich baue eine komplett neue Umgebung damit auf und kann daher gleich
>> auf
>> PostgreSQL 10 aufsetzen.
>>
>> Habt Ihr einen Hinweis oder eine gute Doku für mich, die auf PostgreSQL
>> 10 aufsetzt und mich an das Thema besser einführt?
>>
>> Vielen Dank für Eure Unterstützung,
>>
>> Michael
> Ich antworte dir morgen ausführlich ;-)

Du willst einen Cluster, wo jeder Knoten stets die gleichen Daten hat.
Dazu bietet sich Replikation an.
Vor PostgreSQL 9.0 gab es keine eingebaute Replikation, was dazu führte,
daß es verschiedene Ansätze (externe Lösungen) gab, dies zu realisieren.

so gab (und gibt es) TRIGGER-basierte Lösungen (Slony, Londiste, ...)
die bei z.B. einem INSERT dafür sorgten, daß dieser Datensatz auch in
einer weiteren DB
eingetragen wurde. Nachteil: erhöhter Aufwand auf dem Master (TRIGGER
sind 'teuer'), allerdings gibt es auch einen Vorteil: das funktioniert
auch versionsübergreifend.

Andere Lösung: man schaltet eine Instanz davor, die, wenn sie eine
schreibende Operation erkennt, diese auf 2 oder mehr der angeschlossenen
Instanzen
ausführt. Bestes Beispiel dafür ist pgpool2. Nachteil: diese Instanz
davor muß jede ankommende Query erst einmal selber zerlegen und prüfen,
was diese macht.
Bei einem INSERT ist das noch trivial, bei Funktionen aber nicht mehr.
Insbesondere dann, wenn man selber Stored Procedures schreibt. Ein
"Select * from my_function(10,100)"
macht genau was? Richtig, ohne diese Funktion zu kennen kann man das
nicht sagen. Vor genau diesem Problem steht auch pgpool2.

Seit PostgreSQL 9.0 gibt es die eingebaute "Streaming Replication" (SR).
Diese sorgt für ein binärgleiches Abbild des Masters auf den Standbys.
Dazu werden alle physischen Änderungen (das Transaktionslog)
zu dem oder den Standbys übertragen. Vorteil: (nahezu) keine extra
Belastung auf dem Master, Nachteil: geht nicht versionsübergreifend.

Mit dieser Streaming Replication sind eigentlich die anderen Lösungen
obsolet, weil die Vorteile von SR überwiegen. Nachteil ist, daß es nicht
möglich ist, nur einen Teilset der DB zu replizieren und daß es nicht
möglich ist, das versionsübergreifend zu replizieren.

Um diese Nachteile noch zu lösen, hat insbesondere (aber nicht nur) ein
Team von 2ndQuadrant die physische Replikation von SR (es werden quasi
physische Diffs von Binärdateien übertragen) zu einer logischen
Replikation erweitert. Dazu wird dieser Stream von physischen Diffs
wieder in logische SQL-Befehle übersetzt. Vorteil: damit ist es sowohl
möglich, nur definierte Teile der Gesamtdatenbank zu replizieren als
auch versionsübergreifend zu replizieren. Dazu kommt noch, daß die DB,
in die repliziert wird, weiter schreibbar ist.

Von dieser logischen Replikation gibt es 3 grundlegende Realisierungen:

* logical replication: eingebaut in PG 10. Diese erlaubt z.B. die
Replikation von Tabellen, allerdings keine Filterung (auswahl der zu
replizierenden Datensätze) und auch kein Konflikthandling. Eigene
Befehle wie z.B. CREATE PUBLICATION, CREATE SUBSCRIPTION etc.
/docs/10/static/logical-replication.html
* pglogical: extra Modul, verfügbar ab PG 9.4. mehr Funktionen als
logical replication in PG10, aber nicht im Kern der DB, daher alle
Aufrufen via Function Calls, z.B. pglogical.create_subscription(), siehe
https://www.2ndquadrant.com/en/resources/pglogical/pglogical-docs/
* BDR: Bi-Directional Replication. Das ist eine volle
Multi-Master-Lösung, für wohl maximal 48 gleichzeitige aktive Master.
Ideal für geographisch weit verteilte Systeme, wir haben Kunden mit BDR
und Servern in Amerika, Europa und Asien und eben volle
Multi-Master-Replikation dazwischen. BDR Version 1 ist weiter unter
Support, aber keine neuen Features mehr. Version2 und Version 3(derzeit
Beta, ab Ende Mai wohl verfügbar) sind die aktiv in Entwicklung
befindlichen Versionen.

Was Du brauchst bzw. suchst ist offenbar eine Master-Standby-Lösung
mittels SR. Die Applikation schreibt alle Änderungen in den Master (A)
und kann die Daten auch auf dem Standby (S) lesen.
Falls der Master ausfällt, sollen die Zugriffe auf den Standby gehen und
dieser auch zum Master promotet werden. (man muß noch zwischen
synchroner und asynchroner Replikation unterscheiden)

Zum Aufsetzen einer solchen Replikation empfehlen wir ein Tool, was wir
auch dafür entwickelt haben: repmgr https://repmgr.org/ . Wenn das
korrekt eingerichtet ist, kannst Du via "repmgr standby switchover" z.B.
für eine geplante Wartung am Master die Rollen Master <-> Standby
einfach tauschen. Das ist aber noch keine HA, kein automatisches
Failover. Dazu kann man on top von repmgr noch den passenden Deamon
nutzen, den repmgrd. Dieser überwacht von dem/den Standby(s) den Master
und sorgt bei dessen Ausfall für das automatische Promoten eines Standbys.

Was noch fehlt: wie erfährt das die Applikation? Dafür gibt es, Du ahnst
es, wieder verschiedene Möglichkeiten. JDBC-basierte Applikationen
können das im JDBC-Treiber einstellen, dieser hat ein eingebautes
Auto-Failover. Dazu nennt man in connection-string alle Server (Master
und alle Standbys) und gibt an, was man haben will: den Master oder
'nur' einen Standby. PostgreSQL 10 hat dies nun in der libpq auch.
Damit kannst Du also in der Applikation sagen: es gibt server1, server2,
server3 - bitte suche mir den aktuellen Master und verbinde Dich damit.
Damit hast allerdings noch keine Lastvrteilung, Du landest IMMER auf dem
Master. Ist Deine Applikation schlau genug zu wissen, daß die folgenden
Abfragen alle nur rein lesend sind, könnte diese auch eine weitere
Verbindung zur DB aufbauen und dabei angeben, daß ein ReadOnly-Server,
also Standby, ausreicht.

Ein Wort noch zu pgpool2: dieses kann einfaches connection-pooling, aber
auch Verteilung schreibender Zugriffe auf mehrere Knoten. Das brauchst
Du aber bei SR nicht wirklich. Was bleibt, ist, daß pgpool2 relativ viel
Code ist und relativ aufwendig ist, für etwas, was man eigentlich nicht
braucht. Ein connection-pooler kann aber dennoch durchaus sinnvoll sein.
Die von uns dafür unterstützte Lösung ist pgbouncer.

So, ich hoffe, nun bist Du völlig verunsichert und brauchst eine
weitergehende Beratung von uns ;-)

tl;dr

* nehmt PG10
* nutzt die eingebaute SR
* schaut Euch repmgr an https://repmgr.org/
* prüft, wie sich die Applikation verbindet (libpq, JDBC) und nutzt
dessen Features für Autofailover
* schaut Euch noch Barman an https://www.pgbarman.org/index.html um auch
eine gute Lösung für Backup zu haben
* repmgr und Barman sind von uns entwickelt und werden natürlich durch
uns supportet, sind aber frei nutzbar
* falls ihr einen 24*7*365-Support braucht, fragt uns (bzw. mich)

Falls ihr der Meinung seid, ihr braucht BDR: Version 1 ist frei
verfügbar, würde ich aber nicht (mehr) empfehlen. Versionen 2 und 3
benötigen einen Supportvertrag mit uns. Kein Schnäppchen, aber
erstklassig und auch wirklich sinnvoll. Wir entdecken durch BDR z.B.
immer mal wieder Bugs direkt im PG-Core, und wer BDR einsetzt hat dazu
auch eine kritische Anwendung und braucht dazu auch den Support von uns.
Natürlich finanzieren wir auch die weitere Entwicklung von BDR durch
solche Supportverträge.

Andreas

--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com