Wie modelliere ich einen PostgreSQL-Failover-Cluster mit Docker/Kubernetes?

Question

Ich bin immer noch mit dem Kopf um Kubernetes und wie das funktionieren soll. Derzeit habe ich Probleme zu verstehen, wie man etwas wie einen PostgreSQL-Cluster mit Streaming-Replikation, Skalierung und automatischem Failover/Failback modellieren kann (pgpool-II, repmgr, wähle dein Gift).

Mein Hauptproblem mit dem Ansatz ist die Dual-Natur einer PostgreSQL-Instanz, Konfiguration - es ist entweder ein Master-oder ein Kalt/Warm/Hot-Standby. Wenn ich die Anzahl der Replikate erhöhe, würde ich erwarten, dass sie alle als Standbys erscheinen, also würde ich mir vorstellen, einen postgresql-standby Replikationscontroller separat von einem postgresql-master Pod zu erstellen. Allerdings würde ich auch erwarten, dass einer dieser Bereitschaftskandidaten ein Master wird, falls der aktuelle Master down ist, also ist es ein üblicher Replikations-Controller, postgresql.

Die einzige Idee, die ich bisher hatte, ist, die Replikationskonfiguration auf ein externes Volume zu legen und die Status- und Statusänderungen außerhalb der Container zu verwalten.

(im Fall von PostgreSQL würde die Konfiguration wahrscheinlich bereits auf einem Datenträger innerhalb seines data Verzeichnis, das sich offensichtlich etwas, das ich auf einem Volume wollen würde, aber das ist nebensächlich)

Ist das der richtige Zugang, oder gibt es einen anderen sauberen Weg?

Answer 1

Es gibt ein Beispiel in Openshift: https://github.com/openshift/postgresql/tree/master/examples/replica Das Prinzip ist das gleiche in reiner Kube (es ist nichts mit wirklich Openshift spezifisch, und Sie können die Bilder in einfachen Docker verwenden)

Answer 2

Kubernetes des statefulset ist eine gute Basis für die Einstellung bis der Stateful Service. Sie benötigen noch etwas Arbeit, um die korrekte Mitgliedschaft unter PostgreSQL-Replikaten zu konfigurieren.

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

Answer 3

Sie können PostDock versuchen, entweder mit Docker-Compose oder Kubernetes. Zur Zeit habe ich es in unserem Projekt mit Docker-compose, mit dem Schema versucht, wie unten dargestellt:

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

ich die folgenden Szenarien getestet haben, und sie alle arbeiten sehr gut:

• Replikation: Änderungen Der Failover: stoppt den primären Knoten und ein Standby-Knoten (z. B. node4) übernimmt automatisch die primäre Rolle.
• Vermeidung von zwei primären Knoten: den vorherigen primären Knoten (Knoten1) wiederbeleben, Knoten4 wird als primärer Knoten fortgesetzt, während Knoten1 synchron ist, aber als Standby-Knoten.

Wie bei der Client-Anwendung sind diese Änderungen alle transparent. Der Client zeigt nur auf den pgpool-Knoten und funktioniert in allen oben genannten Szenarios einwandfrei.

Hinweis: Falls Sie Probleme haben PostDock laufen aufstehen, könnten Sie my forked version of PostDock versuchen.

pgpool-II mit Watchdog

Ein Problem mit der oben erwähnten Architektur ist, dass die pgpool Single Point of Failure ist. Also habe ich auch versucht, Watchdog for pgpool-II mit einer delegierten virtuellen IP zu ermöglichen, 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 sie alle arbeiten sehr gut:

• Normalszenario: Beiden pgpools starten, mit der virtuellen IP automatisch zu einem von ihnen angewandt, in meinem Fall, pgpool1
• Failover: Herunterfahren von pgpool1. Die virtuelle IP wird automatisch auf pgpool2 angewendet, das somit aktiv wird.
• Starten fehlgeschlagen pgpool: Starten Sie erneut pgpool1. Die virtuelle IP wird mit pgpool2 beibehalten und pgpool1 arbeitet jetzt als Standby.

Wie bei der Client-Anwendung sind diese Änderungen alle transparent. Der Client zeigt nur auf die virtuelle IP und funktioniert in allen oben genannten Szenarien einwandfrei.

Sie finden dieses Projekt unter my GitHub repository on the watchdog branch.