wake-up-neo.com

Wie modelliere ich einen PostgreSQL-Failovercluster mit Docker/Kubernetes?

Ich bin immer noch mit Kubernetes beschäftigt und wie das funktionieren soll. Momentan habe ich Schwierigkeiten zu verstehen, wie man so etwas wie einen PostgreSQL-Cluster mit Streaming-Replikation, Skalierung und automatischem Failover/Failback modelliert (pgpool-II, repmgr, wählen Sie Ihr Gift).

Mein Hauptproblem bei diesem Ansatz ist die doppelte Natur einer PostgreSQL-Instanz, in Bezug auf die Konfiguration - entweder ein Master oder ein Cold/Warm/Hot-Standby. Wenn ich die Anzahl der Replikate erhöhen würde, würde ich davon ausgehen, dass sie alle als Standbys erscheinen, also kann ich mir vorstellen, einen postgresql-standby-Replikationscontroller separat von einem postgresql-master-Pod zu erstellen. Ich würde jedoch auch erwarten, dass einer dieser Standbys ein Master wird, falls der aktuelle Master ausfällt. Es handelt sich also um einen gängigen postgresql-Replikationscontroller.

Die einzige Idee, die ich bisher hatte, ist, die Replikationskonfiguration auf einem externen Volume zu speichern und den Status und die Statusänderungen außerhalb der Container zu verwalten.

(im Falle von PostgreSQL würde sich die Konfiguration wahrscheinlich bereits auf einem Volume im Verzeichnis data befinden. Dies ist natürlich etwas, das ich auf einem Volume haben möchte, aber das ist nicht der Sinn)

Ist das der richtige Ansatz oder gibt es einen saubereren Weg?

postgresqldockerkubernetes
27
Nikolai Prokoschenko

In OpenShift gibt es ein Beispiel: https://github.com/openshift/postgresql/tree/master/examples/replica Das Prinzip ist in Pure Kube dasselbe (es wird nichts wirklich OpenShift-spezifisches verwendet und Sie können es verwenden die Bilder im einfachen Docker)

10
Clayton

Sie können PostDock versuchen, entweder mit Docker-Compose oder Kubernetes. Derzeit habe ich es in unserem Projekt mit docker-compose ausprobiert, mit dem Schema wie unten gezeigt:

pgmaster (primary node1)  --|
|- pgslave1 (node2)       --|
|  |- pgslave2 (node3)    --|----pgpool (master_slave_mode stream)----client
|- pgslave3 (node4)       --|
   |- pgslave4 (node5)    --|

Ich habe die folgenden Szenarien getestet, und alle funktionieren sehr gut:

  • Replikation: Änderungen, die am primären Knoten (d. H. Master) vorgenommen werden, werden auf alle Standby-Knoten (d. H. Slave) repliziert
  • Failover: Stoppt den Primärknoten und ein Standby-Knoten (z. B. Knoten4) übernimmt automatisch die Primärrolle.
  • Verhinderung von zwei Primärknoten: Wiederaufnahme des vorherigen Primärknotens (Knoten1), Knoten4 wird als Primärknoten fortgeführt, während Knoten1 synchron ist, aber als Standby-Knoten. 

Diese Änderungen sind für die Clientanwendung transparent. Der Client zeigt nur auf den pgpool-Knoten und funktioniert in allen oben genannten Szenarien einwandfrei.

Note: Falls Sie Probleme haben, PostDock zum Laufen zu bringen, können Sie meine verzweigte Version von PostDock versuchen.

Pgpool-II mit Watchdog

Ein Problem bei der oben genannten Architektur besteht darin, dass pgpool der zentrale Ausfallpunkt ist. Also habe ich auch versucht, Watchdog für pgpool-II mit einer delegierten virtuellen IP zu aktivieren, um den Single Point of Failure zu vermeiden.

master (primary node1)  --\
|- slave1 (node2)       ---\     / pgpool1 (active)  \
|  |- slave2 (node3)    ----|---|                     |----client
|- slave3 (node4)       ---/     \ pgpool2 (standby) /
   |- slave4 (node5)    --/

Ich habe die folgenden Szenarien getestet, und alle funktionieren sehr gut: 

  • Normales Szenario: Beide pgpools starten, wobei die virtuelle IP automatisch auf eine von ihnen angewendet wird, in meinem Fall pgpool1
  • Failover: Herunterfahren von pgpool1. Die virtuelle IP wird automatisch auf pgpool2 angewendet, das somit aktiv wird.
  • Starten Sie fehlgeschlagenes pgpool: Starten Sie erneut pgpool1. Die virtuelle IP wird bei pgpool2 beibehalten, und pgpool1 arbeitet jetzt als Standby.

Diese Änderungen sind für die Clientanwendung transparent. Der Client zeigt nur auf die virtuelle IP-Adresse und funktioniert in allen oben genannten Szenarien einwandfrei.

Sie finden dieses Projekt unter my GitHub-Repository im Watchdog-Zweig .

1
Yuci

Das statefulset von Kubernetes ist eine gute Basis für die Einrichtung des stateful-Dienstes. Sie benötigen noch einige Arbeit, um die korrekte Mitgliedschaft zwischen PostgreSQL-Replikaten zu konfigurieren. 

Kubernetes hat ein Beispiel dafür. http://blog.kubernetes.io/2017/02/postgresql-clusters-kubernetes-statefulsets.html

0
CloudStax

Sie können sich eines der folgenden Open-Source-Tools von postgresql ansehen

1 Knusprige Daten postgresql

  1. Patroni postgresql.
0
P Ekambaram