Patroni ist eine Art Cluster-Manager-Framework, welches von vielen Kunden genutzt wird, um PostgreSQL (hoch)verfügbar zu betreiben. In diesem Blog-Beitrag möchten wir Ihnen zeigen, wie einfach ein Setup eines PostgreSQL-Clusters mithilfe dieser Lösung möglich ist. Wir stellen die grundlegenden Komponenten vor und erklären die Funktionsweise. 

Der Grundstein des Clusters 

​Für unser beispielhaftes Setup nutzen wird drei Ubuntu-Linux Server (Docker Container). Die Knoten hören auf die folgenden Namen:

• node1; 172.28.0.2
• node2; 172.28.0.3
• node3; 172.28.0.4

Die Server sind netzwerktechnisch so verbunden und konfiguriert, dass sie miteinander problemlos (über Hostnamen und IPs) kommunizieren können.

Zunächst wurde das aktuelle PostgreSQL-Repository runtergeladen und PostgreSQL in der Version 14 installiert.

Als nächstes wurde etcd installiert. 

Bei etcd handelt es sich um einen hierarchisch verteilten Key-Value-Store. Er dient als Speicher für kritische Informationen von verteilten Anwendungen, so z.B. von Clustern oder komplexen IOT-Systemen. Im Umfeld von PostgreSQL und Patroni wird etcd genutzt, um festzulegen, welches System führend (Leader) ist und welche Systeme von diesem replizieren (Replica). Diese Art von Diensten wird auch DCS (Distributed Consensus Store) genannt. Generell können unterschiedliche DCS-Varianten mit Patroni genutzt werden (so auch z.B. Consul, Zookeeper).

„Last but not least" erfolgte die Installation von Patroni inkl. einer grundlegenden Python-Umgebung mit einiges Zusatzpaketen.

„YAML" nicht rum. 

Die Grundlage unseres Clusters ist etcd. Die Konfiguration erfolgt im YAML-Format uns muss auf jedem Knoten erfolgen: 

Nachdem auch die anderen Knoten (mit den entsprechenden Anpassungen der Hostnamen und IP-Adressen) erfolgt ist, kann der etcd-Dienst gestartet und getestet werden: 

Wir sehen, dass etcd den zweiten Knoten „node1" zum „Leader" erkoren hat. 

Noch mehr zum „YAML"en…

Auch Patroni wird per YAML konfiguriert. Beim initialen Aufruf wird auf dem ersten Knoten das „initdb"-Kommando zur Erstellung der Datenbank aufgerufen. Zusätzlich werden einige weitere User-Accounts zur Cluster-Steuerung angelegt.

Damit wird das Cluster zum Leben erweckt und die Datenbank auf dem ersten Knoten erstellt und mit dem Start der Knoten 2 und 3 dorthin jeweils repliziert.

Das Cluster lässt sich mit dem folgenden Kommando überprüfen:​

Cluster-Spielereien 

Nach diesem Erfolgserlebnis wollen wir noch ein bisschen mit dem Cluster spielen und ein Fehlerszenario simulieren. Dazu stoppen wir den ersten Knoten „node1" und schauen uns den Zustand des Clusters an. 

Der Knoten „node1" ist verschwunden und nicht mehr erreichbar. Der Cluster hat reagiert und den Knoten „node3" zum neuen Leader erkoren. Nun bringen wir den ersten Knoten „node1" wieder ins Spiel. Nach dem Start der etcd- und patroni-Dienste ist der Cluster wieder vollständig, wenn auch in einer neuen Rollenverteilung:

Zum guten Schluss versuchen wir den Originalzustand wieder herzustellen. Dazu „switchen" wir den „Leader" zurück auf „node1".

Direkt nach dem Switchover ist der Knoten „node3" noch nicht wieder als „Replica" online. Daher warten wir ein paar Sekunden und schauen uns den Zustand des Clusters erneut an. 

Nach einigen Sekunden hat sich das Cluster wieder „gefangen". Beide „Replica" hängen wieder am „Leader" „node1".

Fazit 

Ein PostgreSQL Cluster mit Patroni lässt sich schnell aufbauen und recht unkompliziert verwalten. Der Aufwand der Konfiguration hält sich in einem Basis-Setup in Grenzen.

Sie haben Fragen rund um den Betrieb von PostgreSQL? Sprechen Sie uns an. 

Seminarempfehlung