Umsteiger von MariaDB/Galera

Liebe Community,

ich/war ein jahrelanger MariaDB/Galera Anwender und stelle nun nach und nach meine System auf PostgreSQL um.
Allerdings gibt es hierbei einige Fragen, die sich mir stellen:

Galera Cluster läuft bei mir als 3x Master + 1x Slave mit vorgeschaltenem Load/Query-Balancer (MaxScale).
Soweit ich mich eingelesen habe, unterstützt Postgres von Haus aus nur Master-Slave Replikation. Master-Master nur mit 3. Anbietertools auf die ich aktuell nicht zurückgreifen möchte.

Master-Slave Replikation ist für den Moment in Ordnung, allerdings würde ich gerne die Daten auf mehrere Slaves replizieren.
Für die Replikation selbst gibt es ja im postgresql.conf File eine Options namens archive_command = ‘rsync …’
Kann man hier auch mehrere Commands verwenden? Also zB: archive_command = ‘rsync … host 1, rsync … host 2, und so weiter’

Als Loadbalancer wäre mir aktuell HAProxy in den Sinn gekommen, wo man allerdings verschiedene Ports für RoundRobin und Read-only Queries verwenden müsste.

Da ich die Datenbank hauptsächlich für Webanwendungen (Apache2 & PHP7.3) nutze, kenne ich hier keine Modifikationsmöglichkeit, um Queries in Read-only und Updates/Deletes/Insert Into,… zu spalten.
Gibt es auch hier eine Idee?

Vielen Dank für Eure Rückmeldungen!
Mathias

Ich würde die Replikation via streaming replication machen, nicht mittels “WAL shipping”, das ist schneller und stabiler.
Jeder Standby verbindet sich zum Primary server und holt sich dort die WAL information aktiv ab, auf dem Primary müssen keine mehrfachen Kommandos konfiguriert werden. Wenn Du darauf vorbereitet sein willst, dass ein Standby mal ausfällt, bietet es sich an mit Replication Slots zu arbeiten, damit der Master die WAL Archive aufhebt, bis der Standby wieder da ist.

Für das Load-Balancing in einem Primary/Standby cluster würde ich pgBouncer (https://pgbouncer.github.io/) nehmen.

Schaue Dir unseren repmgr mal an ( https://repmgr.org/ ), damit kannst Du sehr einfach eine Streaming Replication aufbauen und verwalten. Wie @castorp schon sagte, Log-Shipping ist NICHT die Lösung.

Wenn Du Multi-Master willst, dann schauen Dir unser BDR an, allerdings ist nur BDR1 frei verfügbar, aber auch nur für 9.4 und nicht höher und der Support sowohl für 9.4 als auch BDR1 läuft im Herbst aus. BDR3 wäre die aktuelle Lösung, aber nicht frei verfügbar. Wenn Du dazu mehr wissen willst - wende Dich vertrauensvoll an mich.

Zu Deiner anderen Frage: die libpq unterstützt seit Version 10 auch folgende Syntax:

host=host1,host2 port=port1,port2 target_session_attrs=any

statt any kannst Du auch read-write angeben, dann landest immer beim aktuellen Master. Du kannst also in Deiner Anwendung 2 Connections zur DB öffnen und Read-only - Abfragen auf den Standby schicken.

Vielen Dank für eure Rückmeldungen!
@akretschmer: BDR1 habe ich mir schon angesehen, aber wie du schon gesagt hast: ist demnächst EOL und nicht für meine Version (10) nutzbar.
Multi-Master muss nicht zwingend sein, war einfach ein Feature von Galera, das ich genutzt habe. Hatte aber auch seine Nachteile - vor allem wenn die Applikation zB den Deadlock nicht kannte.

@castorp: Vielen Dank für den Hinweis bezüglich Loadbalancer. Ich werde mir den mal näher ansehen.
HAProxy dürfte vermutlich weniger im Einsatz sein!?

Eine Frage noch: Gibt es ein empfehlenswertes Programm, mit dem man Postgres, Replikation, PgBouncer, etc. monitoren kann?
Für MariaDB/Galera nutzte ich ClusterControll in der Community Version.
War zwar praktisch zum Anschauen der einzelnen Queries, allerdings sehr mühsam, da man bei der kostenlosen Version eigentlich nur das Monitoring hat. Neuen Failover installieren, LoadBalancer intialisieren, usw. war nur in der Gebühren pflichtigen Version möglich. Soweit so gut.
Da ich meinen Cluster aber selbst konfiguriert habe, hat mir ClusterControl permanent dazwischen gefunkt, da im Hintergrund sehr wohl die Logik am Werken war.
Das würde ich gerne nach Möglichkeit vermeiden.

Das ist ein Bereich mit dem ich wenig zu tun habe.

Aber im Postgres Wiki gibt’s eine Übersicht: https://wiki.postgresql.org/wiki/Monitoring

Frage selbst beantwortet: Laut dem Git Repo von PgBouncer gibt es sehr viele feature requests zu SCRAM Authentifizierung.
Nachdem ich alle User auf MD5 umgstellt habe, funktioniert es problemlos.

Eine Frage hätte ich noch, da Repmgr + Pgbouncer teils nicht so ganz miteinander harmonieren.
Gibt es auch eine Möglichkeit, dass ich nach Pgbouncer noch HAProxy laufen lasse und HAProxy bei Repmgr abruft, wer aktuell der Master ist?