Einführung

Patroni ist eine Vorlage für PostgreSQL-Lösungen zur Hochverfügbarkeit (HA) auf Basis von Python. Es entstand als Fork von Governor , einem Projekt von Compose, und enthält zahlreiche neue Funktionen.

Weitere Hintergrundinformationen:

• PostgreSQL-HA mit Kubernetes und Patroni , Vortrag von Josh Berkus auf der KubeCon 2016 (Video)
• Beitrag im Zalando-Tech-Blog vom Februar 2016

Entwicklungsstand

Patroni wird aktiv weiterentwickelt und nimmt Beiträge entgegen. Weitere Einzelheiten stehen im Abschnitt Mitwirken weiter unten.

Informationen zu neuen Versionen veröffentlichen wir hier .

Technische Voraussetzungen und Installation

Anleitungen zur Installation und zum Upgrade von Patroni auf verschiedenen Plattformen stehen hier .

Anzahl der PostgreSQL-Knoten planen

Patroni-/PostgreSQL-Knoten sind von den DCS-Knoten unabhängig (außer wenn Patroni RAFT selbst implementiert). Daher gibt es keine Mindestanzahl an Knoten. Ein Cluster aus einem Primärserver und einem Standby kann problemlos betrieben werden. Weitere Standby-Knoten können später hinzugefügt werden.

Cluster mit 2 Knoten (Primärserver + Standby) sind üblich und bieten automatisches Failover mit Hochverfügbarkeit. Während eines Failovers besteht vorübergehend keine Redundanz, bis der ausgefallene Knoten wieder beitritt.

DCS-Anforderungen: Der DCS (etcd, ZooKeeper, Consul) muss für zuverlässigen Konsens und Fehlertoleranz mit 3 oder 5 Knoten betrieben werden. Ein einzelner DCS-Cluster kann Informationen für Hunderte oder Tausende Patroni-Cluster speichern, die unterschiedliche namespace/scope-Kombinationen verwenden.

Ausführen und Konfigurieren

Der folgende Abschnitt setzt voraus, dass das Patroni-Repository von https://github.com/patroni/patroni geklont wurde. Insbesondere werden die Beispielkonfigurationen postgres0.yml und postgres1.yml benötigt. Wurde Patroni mit pip installiert, können diese Dateien aus dem Git-Repository bezogen werden; ./patroni.py ist dann unten durch den Befehl patroni zu ersetzen.

Die folgenden Befehle verwenden die etcd-v2-API und erfordern eine etcd-Version mit Unterstützung für --enable-v2, etwa etcd 3.5. Bei etcd 3.6 oder neuer stattdessen die etcd3-Konfiguration von Patroni verwenden, da etcd 3.6 die Unterstützung der v2-API entfernt hat .

Zum Einstieg die folgenden Befehle in verschiedenen Terminals ausführen:

> etcd --data-dir=data/etcd --enable-v2=true
> ./patroni.py postgres0.yml
> ./patroni.py postgres1.yml

Daraufhin startet ein hochverfügbarer Cluster. Verschiedene Einstellungen in den YAML-Dateien ausprobieren, um ihre Auswirkungen auf das Clusterverhalten zu beobachten. Einzelne Komponenten beenden, um das Verhalten des Systems zu testen.

Weitere Dateien postgres*.yml hinzufügen, um einen noch größeren Cluster zu erstellen.

Patroni stellt eine HAProxy -Konfiguration bereit, die der Anwendung einen einzelnen Endpunkt für Verbindungen zum Cluster-Leader bietet. Zur Einrichtung folgende Befehle ausführen:

> haproxy -f haproxy.cfg

> psql --host 127.0.0.1 --port 5000 postgres

YAML-Konfiguration

Ausführliche Informationen zu den Einstellungen für etcd, Consul und ZooKeeper stehen hier . Ein Beispiel enthält postgres0.yml .

Konfiguration über Umgebungsvariablen

Ausführliche Informationen zum Festlegen und Überschreiben von Einstellungen über Umgebungsvariablen stehen hier .

Replikationsmöglichkeiten

Patroni verwendet die Streaming-Replikation von Postgres, die standardmäßig asynchron arbeitet. In der asynchronen Replikationskonfiguration von Patroni lässt sich maximum_lag_on_failover setzen. Diese Einstellung verhindert die Hochstufung eines Followers bei einem Failover, wenn er mehr als die festgelegte Anzahl Bytes hinter dem Leader liegt. Ihr Wert sollte je nach geschäftlichen Anforderungen erhöht oder verringert werden. Für stärkere Garantien zur Dauerhaftigkeit kann auch synchrone Replikation verwendet werden. Einzelheiten stehen in der Dokumentation zu Replikationsmodi .

Anwendungen sollten keine Superuser verwenden

Für Verbindungen aus Anwendungen immer einen Benutzer ohne Superuser-Rechte verwenden. Patroni benötigt Datenbankzugriff, um ordnungsgemäß zu funktionieren. Verwendet eine Anwendung einen Superuser, kann sie möglicherweise den gesamten Verbindungspool belegen, einschließlich der über superuser_reserved_connections für Superuser reservierten Verbindungen. Kann Patroni wegen eines vollen Verbindungspools nicht auf den Primärserver zugreifen, führt dies zu unerwünschtem Verhalten.

Die HA-Lösung testen

Das Testen einer HA-Lösung ist zeitaufwendig und umfasst viele Einflussgrößen. Dies gilt besonders für eine plattformübergreifende Anwendung. Dafür wird ein geschulter Systemadministrator oder Berater benötigt. Die Dokumentation kann dies nicht im Detail abdecken.

Folgende Teile der Infrastruktur sollten auf jeden Fall getestet werden:

• Netzwerk (sowohl das dem System vorgelagerte Netzwerk als auch die NICs $$physisch oder virtuell$$selbst)
• Datenträger-IO
• Dateilimits (nofile unter Linux)
• RAM. Auch bei deaktiviertem oomkiller kann fehlender Arbeitsspeicher Probleme verursachen.
• CPU
• Ressourcenkonkurrenz bei der Virtualisierung (Überbelegung des Hypervisors)
• Sämtliche cgroup-Beschränkungen (wahrscheinlich im Zusammenhang mit den obigen Punkten)
• kill -9 für einen beliebigen postgres-Prozess (außer postmaster!). Dies simuliert einen Segmentation Fault recht gut.

Ein postmaster-Prozess sollte dagegen nicht mit kill -9 beendet werden, da das Beenden des Prozesses allein die zugrunde liegenden Bedingungen eines Ressourcenmangels oder anderer Infrastrukturfehler nicht nachbildet. Besteht die Sorge, dass die Infrastruktur unsicher ist und ein Angreifer kill -9 ausführen könnte, kann kein HA-Verfahren das beheben. Der Angreifer würde den Prozess einfach erneut beenden oder auf andere Weise Schaden anrichten.