Patroni-Konfiguration

• 1: Dynamische Konfigurationseinstellungen
• 2: YAML-Konfigurationseinstellungen
• 3: Umgebungskonfiguration

patroni --generate-sample-config [configfile]

patroni --generate-config [--dsn DSN] [configfile]

patroni --validate-config [configfile] [--ignore-listen-port | -i]

1 - Dynamische Konfigurationseinstellungen

Die dynamische Konfiguration wird im DCS (verteilter Konfigurationsspeicher) gespeichert und auf allen Clusterknoten angewendet.

Zum Ändern der dynamischen Konfiguration kann entweder das Werkzeug patronictl_edit_config oder die REST API von Patroni verwendet werden.

• loop_wait: Anzahl der Sekunden, die die Schleife schläft. Standardwert: 10, kleinster zulässiger Wert: 1
• ttl: TTL für den Erwerb der Leader-Sperre (in Sekunden). Sie entspricht der Zeitspanne bis zum Beginn eines automatischen Failovers. Standardwert: 30, kleinster zulässiger Wert: 20
• retry_timeout: Zeitüberschreitung für Wiederholungsversuche bei DCS- und PostgreSQL-Operationen (in Sekunden). Kürzer andauernde DCS- oder Netzwerkprobleme führen nicht dazu, dass Patroni den Leader herabstuft. Standardwert: 10, kleinster zulässiger Wert: 3

loop_wait + 2 * retry_timeout <= ttl

• maximum_lag_on_failover: maximaler Rückstand eines Followers in Bytes, mit dem er noch an der Leader-Wahl teilnehmen darf.
• primary_race_backoff: verschiebt die Leader-Wahl auf Standbys um primary_race_backoff Sekunden, wenn die WAL-Replikation vom Primärserver noch voranschreitet. Dies minimiert unnötige Failovers durch ein kurzzeitig nicht reagierendes Patroni. Standardwert: 0 (deaktiviert).
• maximum_lag_on_syncnode: maximaler Rückstand eines synchronen Followers in Bytes, bevor er als fehlerhafter Kandidat gilt und durch einen fehlerfreien asynchronen Follower ersetzt wird. Bei mehr als einem Follower verwendet Patroni die höchste Replikat-LSN, andernfalls die aktuelle WAL-LSN des Leaders. Der Standardwert ist -1. Bei einem Wert von 0 oder weniger tauscht Patroni einen fehlerhaften synchronen Follower nicht aus. Den Wert ausreichend hoch wählen, damit Patroni bei hohem Transaktionsaufkommen synchrone Follower nicht häufig austauscht.
• max_timelines_history: maximale Anzahl der im DCS gespeicherten Einträge des Timeline-Verlaufs. Standardwert: 0. Bei 0 wird der vollständige Verlauf im DCS gespeichert.
• primary_start_timeout: Zeit, die ein Primärserver zur Erholung von Fehlern erhält, bevor ein Failover ausgelöst wird (in Sekunden). Der Standardwert beträgt 300 Sekunden. Bei 0 erfolgt das Failover nach Möglichkeit sofort nach Erkennung eines Absturzes. Bei asynchroner Replikation kann ein Failover zum Verlust von Transaktionen führen. Im schlimmsten Fall beträgt die Failover-Zeit bei Ausfall des Primärservers: loop_wait + primary_start_timeout + loop_wait. Ist primary_start_timeout jedoch null, beträgt sie nur loop_wait. Den Wert entsprechend der Abwägung zwischen Dauerhaftigkeit und Verfügbarkeit festlegen.
• primary_stop_timeout: Anzahl der Sekunden, die Patroni beim Stoppen von Postgres warten darf; wirkt nur bei aktiviertem synchronous_mode. Ist der Wert auf > 0 gesetzt und synchronous_mode aktiviert, sendet Patroni SIGKILL an den postmaster, wenn der Stoppvorgang länger als primary_stop_timeout dauert. Den Wert entsprechend der Abwägung zwischen Dauerhaftigkeit und Verfügbarkeit festlegen. Ist der Parameter nicht gesetzt oder auf <= 0 gesetzt, wird primary_stop_timeout nicht angewendet.
• synchronous_mode: aktiviert den synchronen Replikationsmodus. Mögliche Werte: off, on, quorum. In diesem Modus verwaltet der Leader synchronous_standby_names; nur der zuletzt bekannte Leader oder eines der synchronen Replikate darf an der Leader-Wahl teilnehmen. Der synchrone Modus gewährleistet, dass erfolgreich festgeschriebene Transaktionen bei einem Failover nicht verloren gehen. Dafür entfällt die Schreibverfügbarkeit, wenn Patroni die Dauerhaftigkeit der Transaktionen nicht sicherstellen kann. Einzelheiten enthält die Dokumentation der Replikationsmodi .
• synchronous_mode_strict: verhindert das Deaktivieren der synchronen Replikation, wenn keine synchronen Replikate verfügbar sind, und blockiert dadurch alle Schreibzugriffe von Clients auf den Primärserver. Im prioritätsbasierten synchronen Modus (synchronous_mode: on) setzt Patroni 4.1.5 synchronous_standby_names auf *, wenn kein geeignetes synchrones Replikat verfügbar ist. Einzelheiten enthält die Dokumentation der Replikationsmodi .
• synchronous_node_count: bei aktiviertem synchronous_mode verwaltet Patroni mit diesem Parameter die genaue Anzahl synchroner Standby-Instanzen und passt beim Hinzukommen und Ausscheiden von Mitgliedern den Zustand im DCS und den PostgreSQL-Parameter synchronous_standby_names an. Ist der Wert höher als die Anzahl geeigneter Knoten, wird er automatisch angepasst. Standardwert: 1.
• failsafe_mode: aktiviert den DCS-Failsafe-Modus . Standardwert: false.
• postgresql:
  • use_pg_rewind: bestimmt, ob pg_rewind verwendet wird. Standardwert: false. Der Cluster muss mit data page checksums (Option --data-checksums für initdb) initialisiert worden sein und/oder wal_log_hints muss auf on gesetzt sein, andernfalls funktioniert pg_rewind nicht.
  • use_slots: bestimmt, ob Replikationsslots verwendet werden. Standardwert unter PostgreSQL 9.4+: true.
  • recovery_conf: zusätzliche Konfigurationseinstellungen, die beim Konfigurieren eines Followers in recovery.conf geschrieben werden. Ab PostgreSQL 12 gibt es keine recovery.conf mehr; dieser Abschnitt kann dennoch weiter verwendet werden, da Patroni dies transparent handhabt.
  • parameters: Konfigurationsparameter (GUCs) für Postgres im Format {max_connections: 100, wal_level: "replica", max_wal_senders: 10, wal_log_hints: "on"}. Viele davon sind für die Replikation erforderlich.
  • parameters_primary: (optional) rollenspezifische Parameterüberschreibungen für primary. Diese Werte werden mit den grundlegenden parameters zusammengeführt und überschreiben sie.
  • parameters_replica: (optional) rollenspezifische Parameterüberschreibungen für replica. Diese Werte werden mit den grundlegenden parameters zusammengeführt und überschreiben sie.
  • parameters_standby_leader: (optional) rollenspezifische Parameterüberschreibungen für standby_leader. Diese Werte werden mit den grundlegenden parameters zusammengeführt und überschreiben sie.
  • pg_hba: Liste der Zeilen, aus denen Patroni pg_hba.conf erzeugt. Patroni ignoriert diesen Parameter, wenn der PostgreSQL-Parameter hba_file auf einen anderen Wert als den Standardwert gesetzt ist.
    • - host all all 0.0.0.0/0 md5
    • - host replication replicator 127.0.0.1/32 md5: Eine solche Zeile ist für die Replikation erforderlich.
  • pg_hba_primary: (optional) rollenspezifische pg_hba-Einträge für primary. Sie ersetzen pg_hba vollständig (keine Zusammenführung). Sind sie nicht definiert, wird pg_hba verwendet.
  • pg_hba_replica: (optional) rollenspezifische pg_hba-Einträge für replica. Sie ersetzen pg_hba vollständig (keine Zusammenführung). Sind sie nicht definiert, wird pg_hba verwendet.
  • pg_hba_standby_leader: (optional) rollenspezifische pg_hba-Einträge für standby_leader. Sie ersetzen pg_hba vollständig (keine Zusammenführung). Sind sie nicht definiert, wird pg_hba verwendet.
  • pg_ident: Liste der Zeilen, aus denen Patroni pg_ident.conf erzeugt. Patroni ignoriert diesen Parameter, wenn der PostgreSQL-Parameter ident_file auf einen anderen Wert als den Standardwert gesetzt ist.
    • - mapname1 systemname1 pguser1
    • - mapname1 systemname2 pguser2
  • pg_ident_primary: (optional) rollenspezifische pg_ident-Einträge für primary. Sie ersetzen pg_ident vollständig (keine Zusammenführung). Sind sie nicht definiert, wird pg_ident verwendet.
  • pg_ident_replica: (optional) rollenspezifische pg_ident-Einträge für replica. Sie ersetzen pg_ident vollständig (keine Zusammenführung). Sind sie nicht definiert, wird pg_ident verwendet.
  • pg_ident_standby_leader: (optional) rollenspezifische pg_ident-Einträge für standby_leader. Sie ersetzen pg_ident vollständig (keine Zusammenführung). Sind sie nicht definiert, wird pg_ident verwendet.
• standby_cluster: ist dieser Abschnitt definiert, soll ein Standby-Cluster initialisiert werden.
  • host: Adresse des entfernten Knotens
  • port: Port des entfernten Knotens
  • primary_slot_name: auf dem entfernten Knoten für die Replikation zu verwendender Slot. Dieser Parameter ist optional; der Standardwert wird aus dem Instanznamen abgeleitet (siehe Funktion slot_name_from_member_name).
  • create_replica_methods: geordnete Liste der Methoden, mit denen ein Standby-Leader vom entfernten Primärserver initialisiert werden kann. Sie kann sich von der in postgresql_settings definierten Liste unterscheiden.
  • restore_command: Befehl zur Wiederherstellung von WAL-Einträgen des entfernten Primärservers auf den Knoten eines Standby-Clusters. Er kann sich von der in postgresql_settings definierten Liste unterscheiden.
  • archive_cleanup_command: Bereinigungsbefehl für den Standby-Leader
  • recovery_min_apply_delay: Wartezeit vor dem tatsächlichen Anwenden von WAL-Einträgen auf einem Standby-Leader
• member_slots_ttl: Aufbewahrungszeit physischer Replikationsslots für heruntergefahrene Replikate. Standardwert: 30min. Bei 0 bleibt das bisherige Verhalten erhalten (der Slot wird sofort entfernt, wenn der Mitgliedsschlüssel im DCS abläuft). Die Funktion wird erst ab PostgreSQL 11 unterstützt.
• slots: definiert permanente Replikationsslots. Diese Slots bleiben bei einem Switchover/Failover erhalten. Nicht vorhandene permanente Slots werden von Patroni erstellt. Ab PostgreSQL 11 werden permanente physische Slots auf allen Knoten angelegt und ihre Position alle loop_wait Sekunden vorgerückt. Bei PostgreSQL-Versionen vor 11 werden permanente physische Replikationsslots nur auf dem aktuellen Primärserver verwaltet. Logische Slots werden mit einem Neustart vom Primärserver auf einen Standby kopiert; anschließend wird ihre Position bei Bedarf alle loop_wait Sekunden vorgerückt. Das Kopieren der Dateien logischer Slots erfolgt über eine libpq-Verbindung mit den Zugangsdaten für rewind oder den Superuser (siehe Abschnitt postgresql.authentication). Die Position eines logischen Slots auf dem Replikat kann immer etwas hinter der des bisherigen Primärservers liegen. Daher sollte die Anwendung darauf vorbereitet sein, dass einige Nachrichten nach einem Failover erneut empfangen werden können. Am einfachsten lässt sich dies durch Verfolgen von confirmed_flush_lsn handhaben. Permanente Replikationsslots erfordern, dass postgresql.use_slots auf true gesetzt ist. Sind permanente logische Replikationsslots definiert, aktiviert Patroni automatisch hot_standby_feedback. Da das Failover logischer Replikationsslots unter PostgreSQL 9.6 und älter unsicher ist und PostgreSQL 10 einige wichtige Funktionen fehlen, wird diese Funktion nur unter PostgreSQL 11+ unterstützt.
  • my_slot_name: Name des permanenten Replikationsslots. Entspricht der Name des permanenten Slots dem Namen des aktuellen Knotens, wird er auf diesem Knoten nicht erstellt. Wird ein permanenter physischer Replikationsslot hinzugefügt, dessen Name dem eines Patroni-Mitglieds entspricht, stellt Patroni sicher, dass der erstellte Slot auch dann nicht entfernt wird, wenn das zugehörige Mitglied nicht mehr reagiert. Normalerweise würde Patroni den Slot in dieser Situation entfernen. Das kann nützlich sein, etwa wenn die von Mitgliedern verwendeten Replikationsslots während vorübergehender Ausfälle erhalten bleiben sollen oder bestehende Mitglieder in einen neuen Patroni-Cluster übernommen werden (siehe Eine eigenständige Instanz in einen Patroni-Cluster überführen ). Betreiber sollten jedoch darauf achten, solche Namensüberschneidungen nicht im DCS zu belassen, wenn der Slot nicht mehr benötigt wird, da sie den normalen Betrieb von Patroni beeinflussen.
    • type: Slot-Typ. Möglich sind physical oder logical. Bei einem logischen Slot müssen zusätzlich database und plugin definiert werden. Bei einem physischen Slot kann optional cluster_type definiert werden.
    • database: Name der Datenbank, in der logische Slots erstellt werden sollen.
    • plugin: Name des Plugins für den logischen Slot.
    • cluster_type: Clustertyp (primary oder standby), auf dem der Slot ausschließlich erstellt werden soll. Andernfalls wird er nicht erstellt beziehungsweise ein bereits vorhandener Slot gelöscht.
• ignore_slots: Liste von Gruppen von Replikationsslot-Eigenschaften; Patroni soll Slots ignorieren, die diesen Eigenschaften entsprechen. Diese Konfiguration/Funktion ist nützlich, wenn einige Replikationsslots außerhalb von Patroni verwaltet werden. Jede passende Teilmenge von Eigenschaften führt dazu, dass ein Slot ignoriert wird.
  • name: Name des Replikationsslots.
  • type: Slot-Typ. Möglich sind physical oder logical. Bei einem logischen Slot können zusätzlich database und/oder plugin definiert werden.
  • database: Datenbankname (beim Abgleich eines logical-Slots).
  • plugin: Plugin für logische Dekodierung (beim Abgleich eines logical-Slots).

Hinweis: slots ist eine Hashmap, ignore_slots dagegen ein Array. Beispiel:

slots:
  permanent_logical_slot_name:
    type: logical
    database: my_db
    plugin: test_decoding
  permanent_physical_slot_name:
    type: physical
  ...
ignore_slots:
  - name: ignored_logical_slot_name
    type: logical
    database: my_db
    plugin: test_decoding
  - name: ignored_physical_slot_name
    type: physical
  ...

Hinweis: Unter PostgreSQL v11 oder neuer verwaltet Patroni physische Replikationsslots auf allen Knoten, die potenziell Leader werden können. Replikatknoten halten dadurch WAL-Segmente vor, die andere Knoten möglicherweise benötigen. Ist ein Knoten nicht verfügbar und läuft sein Mitgliedsschlüssel im DCS ab, wird der zugehörige Replikationsslot nach member_slots_ttl entfernt (Standardwert 30min). Die Aufbewahrungszeit kann je nach Bedarf erhöht oder verringert werden. Bei einer statischen Clustertopologie (feste Anzahl von Knoten, deren Namen sich nie ändern) können alternativ permanente physische Replikationsslots mit den Namen der Knoten konfiguriert werden. So werden Slots nicht entfernt und WAL-Dateien nicht wiederverwendet, während ein Replikat vorübergehend ausgefallen ist:

slots:
  node_name1:
    type: physical
  node_name2:
    type: physical
  node_name3:
    type: physical
  ...

2 - YAML-Konfigurationseinstellungen

Global/Allgemein

• thread_pool_size: Größe des Threadpools, mit dem Patroni asynchrone Aufgaben ausführt und während der Leader-Wahl oder bei Failsafe-Prüfungen über die REST API mit anderen Mitgliedern kommuniziert. Mindestwert: 5, Standardwert: 5.
• thread_stack_size: legt die Stackgröße für von Patroni gestartete Threads fest. Der Wert muss an 64kB ausgerichtet sein. Mindestwert: 64kB, Standardwert (von Patroni gesetzt): 512kB.
• name: Name des Hosts. Er muss im Cluster eindeutig sein.
• namespace: Pfad im Konfigurationsspeicher, unter dem Patroni Informationen über den Cluster speichert. Standardwert: “/service”
• scope: Clustername

Protokollierung

• type: legt das Protokollformat fest. Mögliche Werte sind plain und json. Für das Format json muss jsonlogger installiert sein. Der Standardwert ist plain.
• level: legt die allgemeine Protokollierungsstufe fest. Standardwert: INFO (siehe Dokumentation der Python-Protokollierung )
• traceback_level: legt die Stufe fest, auf der Tracebacks sichtbar sind. Standardwert: ERROR. Auf DEBUG setzen, wenn Tracebacks nur bei aktiviertem log.level=DEBUG sichtbar sein sollen.
• format: legt die Formatzeichenfolge für Protokolle fest. Beim Protokolltyp plain sollte das Format eine Zeichenfolge sein. Verfügbare Attribute stehen unter LogRecord-Attribute . Beim Protokolltyp json kann das Format neben einer Zeichenfolge auch eine Liste sein. Jeder Listeneintrag sollte einem LogRecord-Attribut entsprechen. Dabei wird nur der Feldname benötigt; %( und ) sollten weggelassen werden. Um ein Protokollfeld unter einem anderen Schlüsselnamen auszugeben, ein Dictionary verwenden: Der Schlüssel bezeichnet das Protokollfeld, der Wert den im Protokoll auszugebenden Feldnamen. Standardwert: %(asctime)s %(levelname)s: %(message)s
• dateformat: legt die Formatzeichenfolge für Datum und Uhrzeit fest (siehe Dokumentation zu formatTime() ).
• static_fields: fügt dem Protokoll zusätzliche Felder hinzu. Diese Option ist nur verfügbar, wenn der Protokolltyp auf json gesetzt ist.
• max_queue_size: Patroni verwendet eine zweistufige Protokollierung. Protokolleinträge werden in eine Warteschlange im Arbeitsspeicher geschrieben; ein separater Thread entnimmt sie und schreibt sie nach stderr oder in eine Datei. Die interne Warteschlange ist standardmäßig auf 1000 Einträge begrenzt, was für die Protokolle der letzten 1h20m ausreicht.
• dir: Verzeichnis für die Anwendungsprotokolle. Es muss existieren und für den Benutzer, der Patroni ausführt, beschreibbar sein. Ist dieser Wert gesetzt, bewahrt die Anwendung standardmäßig 4 Protokolldateien mit jeweils 25MB auf. Diese Aufbewahrungswerte lassen sich mit file_num und file_size anpassen (siehe unten).
• mode: Berechtigungen für Protokolldateien (z. B. 0644). Ohne Angabe werden die Berechtigungen anhand des aktuellen umask-Werts gesetzt.
• file_num: Anzahl der aufzubewahrenden Anwendungsprotokolle.
• file_size: Größe der Datei patroni.log (in Bytes), bei der eine Protokollrotation ausgelöst wird.
• loggers: dieser Abschnitt ermöglicht das Neufestlegen der Protokollierungsstufe je Python-Modul
  • patroni.postmaster: WARNING
  • urllib3: DEBUG
• deduplicate_heartbeat_logs: bei true werden aufeinanderfolgende identische Heartbeat-Protokolleinträge nicht ausgegeben. Standardwert: false.

Das folgende Beispiel konfiguriert Patroni für die Protokollierung im JSON-Format.

log:
   type: json
   format:
      - message
      - module
      - asctime: '@timestamp'
      - levelname: level
   static_fields:
      app: patroni

Bootstrap-Konfiguration

• bootstrap:

  • dcs: dieser Abschnitt wird nach der Initialisierung des neuen Clusters in /<namespace>/<scope>/config des angegebenen Konfigurationsspeichers geschrieben. Er enthält die globale dynamische Konfiguration des Clusters. Unter bootstrap.dcs können alle unter Dynamische Konfigurationseinstellungen beschriebenen Parameter angegeben werden. Nachdem Patroni den neuen Cluster initialisiert hat (Bootstrap), schreibt es diesen Abschnitt in /<namespace>/<scope>/config des Konfigurationsspeichers.

  • method: benutzerdefiniertes Skript zur Initialisierung dieses Clusters.

    Einzelheiten enthält die Dokumentation benutzerdefinierter Bootstrap-Methoden . Bei Angabe von initdb wird der standardmäßige Befehl initdb verwendet. initdb wird auch aufgerufen, wenn die Konfigurationsdatei keinen Parameter method enthält.

  • initdb: (optional) Liste der an initdb zu übergebenden Optionen.

    • - data-checksums: muss aktiviert sein, wenn pg_rewind unter 9.3 benötigt wird.
    • - encoding: UTF8: Standardzeichencodierung für neue Datenbanken.
    • - locale: UTF8: Standard-Locale für neue Datenbanken.

  • post_bootstrap oder post_init: Zusätzliches Skript, das nach der Initialisierung des Clusters ausgeführt wird. Es erhält eine Verbindungs-URL (mit dem Cluster-Superuser als Benutzername). Die Variable PGPASSFILE wird auf den Pfad der pgpass-Datei gesetzt.

Citus

Aktiviert die Integration von Patroni mit Citus . Ist sie konfiguriert, übernimmt Patroni die Registrierung der Citus-Worker-Knoten beim Coordinator. Weitere Informationen zur Citus-Unterstützung stehen hier .

• group: Citus-Gruppen-ID als Ganzzahl. Für den Coordinator 0 verwenden, für Worker 1, 2 usw.
• database: Datenbank, in der die Erweiterung citus erstellt werden sollte. Sie muss auf dem Coordinator und allen Workern identisch sein. Derzeit wird nur eine Datenbank unterstützt.

Consul

Die meisten Parameter sind optional, aber host oder url muss angegeben werden.

• host: host:port des lokalen Consul-Agenten.
• url: URL des lokalen Consul-Agenten im Format: http(s)://host:port
• port: (optional) Consul-Port
• scheme: (optional) http oder https, Standardwert http
• token: (optional) ACL-Token
• verify: (optional) bestimmt, ob das SSL-Zertifikat bei HTTPS-Anfragen geprüft wird
• cacert: (optional) CA-Zertifikat. Falls vorhanden, wird die Validierung aktiviert.
• cert: (optional) Datei mit dem Clientzertifikat
• key: (optional) Datei mit dem Clientschlüssel. Kann leer sein, wenn der Schlüssel Bestandteil von cert ist.
• dc: (optional) Rechenzentrum, mit dem kommuniziert werden soll. Standardmäßig wird das Rechenzentrum des Hosts verwendet.
• consistency: (optional) wählt den Konsistenzmodus von Consul. Mögliche Werte: default, consistent oder stale (Einzelheiten in der Consul-API-Referenz )
• checks: (optional) Liste der für die Sitzung verwendeten Consul Health Checks. Standardmäßig wird eine leere Liste verwendet.
• register_service: (optional) bestimmt, ob ein Dienst registriert wird, dessen Name durch den Parameter scope festgelegt ist und der je nach Knotenrolle das Tag master, primary, replica oder standby-leader erhält. Standardwert false
• service_tags: (optional) zusätzliche statische Tags für den Consul-Dienst neben der Rolle (primary/replica/standby-leader). Standardmäßig wird eine leere Liste verwendet.
• service_check_interval: (optional) Häufigkeit der Health Checks für die registrierte URL. Standardwert: ‘5s’.
• service_check_tls_server_name: (optional) überschreibt den SNI-Host bei TLS-Verbindungen; siehe auch die API-Referenz für Consul-Agent-Prüfungen .

token benötigt folgende ACL-Berechtigungen:

service_prefix "${scope}" {
    policy = "write"
}
key_prefix "${namespace}/${scope}" {
    policy = "write"
}
session_prefix "" {
    policy = "write"
}

etcd

Die meisten Parameter sind optional, aber einer der Parameter host, hosts, url, proxy oder srv muss angegeben werden.

• host: host:port des etcd-Endpunkts.
• hosts: Liste der etcd-Endpunkte im Format host1:port1,host2:port2,etc… Möglich sind eine durch Kommas getrennte Zeichenfolge oder eine YAML-Liste.
• use_proxies: ist dieser Parameter auf true gesetzt, behandelt Patroni hosts als Liste von Proxys und ermittelt nicht die Topologie des etcd-Clusters.
• url: URL für etcd.
• proxy: Proxy-URL für etcd. Bei einer Verbindung zu etcd über einen Proxy diesen Parameter anstelle von url verwenden.
• srv: Domain, in der nach SRV-Einträgen für die automatische Clustererkennung gesucht wird. Patroni fragt für die angegebene Domain diese SRV-Dienstnamen ab (in dieser Reihenfolge bis zum ersten Erfolg): _etcd-client-ssl, _etcd-client, _etcd-ssl, _etcd, _etcd-server-ssl, _etcd-server. Werden SRV-Einträge für _etcd-server-ssl oder _etcd-server gefunden, wird über das ETCD-Peer-Protokoll bei ETCD nach verfügbaren Mitgliedern gefragt. Andernfalls werden die Hosts aus den SRV-Einträgen verwendet.
• srv_suffix: konfiguriert ein Suffix für den bei der Erkennung abgefragten SRV-Namen. Mit diesem Flag lassen sich mehrere etcd-Cluster unter derselben Domain unterscheiden. Es funktioniert nur zusammen mit srv. Sind beispielsweise srv_suffix: foo und srv: example.org gesetzt, wird folgende DNS-SRV-Abfrage ausgeführt: _etcd-client-ssl-foo._tcp.example.org (entsprechend für jeden möglichen ETCD-SRV-Dienstnamen).
• protocol: (optional) http oder https; ohne Angabe wird http verwendet. Ist url oder proxy angegeben, wird das Protokoll daraus übernommen.
• username: (optional) Benutzername für die etcd-Authentifizierung.
• password: (optional) Passwort für die etcd-Authentifizierung.
• cacert: (optional) CA-Zertifikat. Falls vorhanden, wird die Validierung aktiviert.
• cert: (optional) Datei mit dem Clientzertifikat
• key: (optional) Datei mit dem Clientschlüssel. Kann leer sein, wenn der Schlüssel Bestandteil von cert ist.

Etcdv3

Damit Patroni mit dem etcd-Cluster über Protokollversion 3 arbeitet, muss in der Patroni-Konfigurationsdatei der Abschnitt etcd3 verwendet werden. Alle Konfigurationsparameter entsprechen denen für etcd.

ZooKeeper

• hosts: Liste der ZooKeeper-Clustermitglieder im Format: $$'host1:port1', 'host2:port2', 'etc...'$$.
• use_ssl: (optional) bestimmt, ob SSL verwendet wird. Standardwert: false. Bei false werden alle SSL-spezifischen Parameter ignoriert.
• cacert: (optional) CA-Zertifikat. Falls vorhanden, wird die Validierung aktiviert.
• cert: (optional) Datei mit dem Clientzertifikat.
• key: (optional) Datei mit dem Clientschlüssel.
• key_password: (optional) Passwort für den Clientschlüssel.
• verify: (optional) bestimmt, ob das Zertifikat geprüft wird. Standardwert: true.
• set_acls: (optional) falls gesetzt, wird Kazoo so konfiguriert, dass es auf jeden neu erstellten ZNode eine Standard-ACL anwendet. ACLs können das Schema x509 (Standard) oder andere unterstützte ZooKeeper-Schemata wie digest verwenden. Sie sollten als Dictionary angegeben werden, dessen Schlüssel der vollständige Principal (optional mit vorangestelltem Schema) und dessen Wert eine Liste von Berechtigungen ist. Als Berechtigungen sind eine oder mehrere aus CREATE, READ, WRITE, DELETE, ADMIN oder ALL möglich. Beispiel: set_acls: {CN=principal1: [CREATE, READ], digest:principal2:+pjROuBuuwNNSujKyH8dGcEnFPQ=: [ALL]}.
• auth_data: (optional) Zugangsdaten für die Verbindung. Sollte ein Dictionary mit scheme als Schlüssel und credential als Wert sein. Standardwert ist ein leeres Dictionary.

Exhibitor

• hosts: anfängliche Liste der Exhibitor-Knoten (ZooKeeper) im Format: ‘host1,host2,etc…’. Diese Liste wird bei jeder Änderung der Topologie des Exhibitor-Clusters (ZooKeeper) automatisch aktualisiert.
• poll_interval: Häufigkeit, mit der die Liste der ZooKeeper- und Exhibitor-Knoten von Exhibitor aktualisiert werden sollte.
• port: Exhibitor-Port.

Kubernetes

• bypass_api_service: (optional) bei der Kommunikation mit der Kubernetes API verwendet Patroni normalerweise den Dienst kubernetes , dessen Adresse den Pods über die Umgebungsvariable KUBERNETES_SERVICE_HOST bereitgestellt wird. Ist bypass_api_service auf true gesetzt, ermittelt Patroni die Liste der API-Knoten hinter dem Dienst und verbindet sich direkt mit ihnen.
• namespace: (optional) Kubernetes-Namespace, in dem der Patroni-Pod läuft. Standardwert: default.
• labels: Labels im Format {label1: value1, label2: value2}. Mit diesen Labels werden vorhandene Objekte (Pods sowie Endpoints oder ConfigMaps) gesucht, die zum aktuellen Cluster gehören. Außerdem setzt Patroni sie auf jedem von ihm erstellten Objekt (Endpoint oder ConfigMap).
• scope_label: (optional) Name des Labels mit dem Clusternamen. Standardwert: cluster-name.
• bootstrap_labels: (optional) Labels im Format {label1: value1, label2: value2}. Sie werden einem Patroni-Pod zugewiesen, wenn sein Zustand initializing new cluster, running custom bootstrap script, starting after custom bootstrap oder creating replica ist.
• role_label: (optional) Name des Labels mit der Rolle (primary, replica oder ein anderer benutzerdefinierter Wert). Patroni setzt dieses Label auf dem Pod, in dem es läuft. Standardwert: role.
• leader_label_value: (optional) Wert des Pod-Labels, wenn die Postgres-Rolle primary ist. Standardwert: primary.
• follower_label_value: (optional) Wert des Pod-Labels, wenn die Postgres-Rolle replica ist. Standardwert: replica.
• standby_leader_label_value: (optional) Wert des Pod-Labels, wenn die Postgres-Rolle standby_leader ist. Standardwert: primary.
• tmp_role_label: (optional) Name des temporären Labels mit der Rolle (primary oder replica). Der Wert dieses Labels entspricht immer dem Standardwert der jeweiligen Rolle. Nur bei Bedarf setzen.
• use_endpoints: (optional) bei true verwendet Patroni Endpoints anstelle von ConfigMaps für die Leader-Wahl und zum Speichern des Clusterzustands.
• pod_ip: (optional) IP-Adresse des Pods, in dem Patroni läuft. Dieser Wert ist erforderlich, wenn use_endpoints aktiviert ist, und wird beim Hochstufen von PostgreSQL im Pod zum Befüllen der Subsets des Leader-Endpoints verwendet.
• ports: (optional) enthält das Service-Objekt einen Namen für den Port, muss derselbe Name im Endpoint-Objekt erscheinen; andernfalls funktioniert der Dienst nicht. Ist der Dienst beispielsweise als {Kind: Service, spec: {ports: [{name: postgresql, port: 5432, targetPort: 5432}]}} definiert, muss kubernetes.ports: [{"name": "postgresql", "port": 5432}] gesetzt werden. Patroni verwendet dies zum Aktualisieren der Subsets des Leader-Endpoints. Dieser Parameter wird nur verwendet, wenn kubernetes.use_endpoints gesetzt ist.
• cacert: (optional) gibt die CA_BUNDLE-Datei mit den Zertifikaten vertrauenswürdiger CAs an, die zum Prüfen der SSL-Zertifikate der Kubernetes API verwendet werden. Ohne Angabe verwendet Patroni den Wert aus dem ServiceAccount-Secret.
• retriable_http_codes: (optional) Liste der HTTP-Statuscodes der K8s API, bei denen ein erneuter Versuch erfolgt. Standardmäßig wiederholt Patroni die Anfrage bei 500, 503 und 504 oder wenn die Antwort der K8s API den HTTP-Header retry-after enthält.

Raft (veraltet)

• self_addr: ip:port, an dem auf Raft-Verbindungen gewartet wird. self_addr muss von anderen Clusterknoten aus erreichbar sein. Ohne Angabe nimmt der Knoten nicht am Konsens teil.

• bind_addr: (optional) ip:port, an dem auf Raft-Verbindungen gewartet wird. Ohne Angabe wird self_addr verwendet.

• partner_addrs: Liste der anderen Patroni-Knoten im Cluster im Format:

  $$'ip1:port', 'ip2:port', 'etc...'$$

• data_dir: Verzeichnis zum Speichern des Raft-Logs und des Snapshots. Ohne Angabe wird das aktuelle Arbeitsverzeichnis verwendet.

• password: (optional) verschlüsselt den Raft-Datenverkehr mit dem angegebenen Passwort; erfordert das Python-Modul cryptography.

• min_timeout: (optional) minimale Zeitüberschreitung für Wahlen in der zugrunde liegenden Raft-Implementierung pysyncobj, in Sekunden. Muss größer als 3 * append_entries_period sein. Standardwert: 0.4.

• max_timeout: (optional) maximale Zeitüberschreitung für Wahlen in der zugrunde liegenden Raft-Implementierung pysyncobj, in Sekunden. Muss größer als min_timeout sein. Standardwert: 1.4.

• connection_timeout: (optional) Zeit in Sekunden, nach der eine Verbindung ohne Datenempfang als unterbrochen gilt. Muss größer oder gleich max_timeout sein. Standardwert: 3.5.

• append_entries_period: (optional) Intervall in Sekunden zum Senden von Heartbeat-Befehlen (append_entries). Muss kleiner als ein Drittel von min_timeout sein. Standardwert: 0.1.

• connection_retry_time: (optional) Intervall in Sekunden zwischen erneuten Verbindungsversuchen zu nicht erreichbaren Knoten. Standardwert: 5.0.

• leader_fallback_timeout: (optional) Zeit in Sekunden, nach der ein Leader ohne Antwort von der Mehrheit in den Follower-Zustand zurückkehrt. Muss größer als append_entries_period sein. Standardwert: 30.0.

Kurze FAQ zur Raft-Implementierung

• F: Wie lassen sich alle am Konsens beteiligten Knoten auflisten?

  A: syncobj_admin -conn host:port -status, wobei host:port die Adresse eines Clusterknotens ist.

• F: Ein am Konsens beteiligter Knoten ist ausgefallen, und seine IP-Adresse kann nicht für einen anderen Knoten wiederverwendet werden. Wie lässt sich dieser Knoten aus dem Konsens entfernen?

  A: syncobj_admin -conn host:port -remove host2:port2, wobei host2:port2 die Adresse des Knotens ist, der aus dem Konsens entfernt werden soll.

• F: Woher bekommt man das Werkzeug syncobj_admin?

  A: Es wird zusammen mit dem Modul pysyncobj (RAFT-Implementierung in Python) installiert, von dem Patroni abhängt.

• F: Kann ein Patroni-Knoten betrieben werden, ohne ihn in den Konsens aufzunehmen?

  A: Ja, dazu raft.self_addr in der Patroni-Konfiguration auskommentieren oder entfernen.

• F: Können Patroni und PostgreSQL auf nur zwei Knoten betrieben werden?

  A: Ja, auf dem dritten Knoten kann patroni_raft_controller laufen (ohne Patroni und PostgreSQL). Bei dieser Konfiguration kann ein Knoten vorübergehend ausfallen, ohne den Primärserver zu beeinträchtigen.

PostgreSQL

• postgresql:

  • authentication:

    • superuser:
      • username: Name des Superusers, der bei der Initialisierung (initdb) festgelegt und später von Patroni für Verbindungen zu Postgres verwendet wird.
      • password: Passwort des Superusers, das bei der Initialisierung (initdb) festgelegt wird.
      • sslmode: (optional) entspricht dem Verbindungsparameter sslmode , der dem Client die Auswahl des Modus für die TLS-Aushandlung mit dem Server erlaubt. Einzelheiten zur Funktionsweise der einzelnen Modi stehen in der PostgreSQL-Dokumentation . Der Standardmodus ist prefer.
      • sslkey: (optional) entspricht dem Verbindungsparameter sslkey , der den Speicherort des geheimen Schlüssels für das Clientzertifikat angibt.
      • sslpassword: (optional) entspricht dem Verbindungsparameter sslpassword , der das Passwort für den in sslkey angegebenen geheimen Schlüssel festlegt.
      • sslcert: (optional) entspricht dem Verbindungsparameter sslcert , der den Speicherort des Clientzertifikats angibt.
      • sslrootcert: (optional) entspricht dem Verbindungsparameter sslrootcert , der den Pfad zu einer Datei mit einem oder mehreren Zertifikaten von Zertifizierungsstellen (CA) angibt, mit denen der Client ein Serverzertifikat prüft.
      • sslcrl: (optional) entspricht dem Verbindungsparameter sslcrl , der den Pfad zu einer Datei mit einer Zertifikatsperrliste angibt. Ein Client lehnt Verbindungen zu Servern ab, deren Zertifikat in dieser Liste enthalten ist.
      • sslcrldir: (optional) entspricht dem Verbindungsparameter sslcrldir , der den Pfad zu einem Verzeichnis mit Dateien angibt, die eine Zertifikatsperrliste enthalten. Ein Client lehnt Verbindungen zu Servern ab, deren Zertifikat in dieser Liste enthalten ist.
      • sslnegotiation: (optional) entspricht dem Verbindungsparameter sslnegotiation , der steuert, wie die SSL-Verschlüsselung mit dem Server ausgehandelt wird, falls SSL verwendet wird.
      • gssencmode: (optional) entspricht dem Verbindungsparameter gssencmode , der bestimmt, ob und mit welcher Priorität eine sichere GSS-Verbindung über TCP/IP mit dem Server ausgehandelt wird.
      • channel_binding: (optional) entspricht dem Verbindungsparameter channel_binding , der die Verwendung von Channel Binding durch den Client steuert.
    • replication:
      • username: Benutzername für die Replikation; der Benutzer wird bei der Initialisierung erstellt. Replikate verwenden ihn, um per Streaming-Replikation auf die Replikationsquelle zuzugreifen.
      • password: Passwort für die Replikation; der Benutzer wird bei der Initialisierung erstellt.
      • sslmode: (optional) entspricht dem Verbindungsparameter sslmode , der dem Client die Auswahl des Modus für die TLS-Aushandlung mit dem Server erlaubt. Einzelheiten zur Funktionsweise der einzelnen Modi stehen in der PostgreSQL-Dokumentation . Der Standardmodus ist prefer.
      • sslkey: (optional) entspricht dem Verbindungsparameter sslkey , der den Speicherort des geheimen Schlüssels für das Clientzertifikat angibt.
      • sslpassword: (optional) entspricht dem Verbindungsparameter sslpassword , der das Passwort für den in sslkey angegebenen geheimen Schlüssel festlegt.
      • sslcert: (optional) entspricht dem Verbindungsparameter sslcert , der den Speicherort des Clientzertifikats angibt.
      • sslrootcert: (optional) entspricht dem Verbindungsparameter sslrootcert , der den Pfad zu einer Datei mit einem oder mehreren Zertifikaten von Zertifizierungsstellen (CA) angibt, mit denen der Client ein Serverzertifikat prüft.
      • sslcrl: (optional) entspricht dem Verbindungsparameter sslcrl , der den Pfad zu einer Datei mit einer Zertifikatsperrliste angibt. Ein Client lehnt Verbindungen zu Servern ab, deren Zertifikat in dieser Liste enthalten ist.
      • sslcrldir: (optional) entspricht dem Verbindungsparameter sslcrldir , der den Pfad zu einem Verzeichnis mit Dateien angibt, die eine Zertifikatsperrliste enthalten. Ein Client lehnt Verbindungen zu Servern ab, deren Zertifikat in dieser Liste enthalten ist.
      • sslnegotiation: (optional) entspricht dem Verbindungsparameter sslnegotiation , der steuert, wie die SSL-Verschlüsselung mit dem Server ausgehandelt wird, falls SSL verwendet wird.
      • gssencmode: (optional) entspricht dem Verbindungsparameter gssencmode , der bestimmt, ob und mit welcher Priorität eine sichere GSS-Verbindung über TCP/IP mit dem Server ausgehandelt wird.
      • channel_binding: (optional) entspricht dem Verbindungsparameter channel_binding , der die Verwendung von Channel Binding durch den Client steuert.
    • rewind:
      • username: (optional) Name des Benutzers für pg_rewind; er wird bei der Initialisierung von Postgres 11+ erstellt und erhält alle erforderlichen Berechtigungen .
      • password: (optional) Passwort des Benutzers für pg_rewind; er wird bei der Initialisierung erstellt.
      • sslmode: (optional) entspricht dem Verbindungsparameter sslmode , der dem Client die Auswahl des Modus für die TLS-Aushandlung mit dem Server erlaubt. Einzelheiten zur Funktionsweise der einzelnen Modi stehen in der PostgreSQL-Dokumentation . Der Standardmodus ist prefer.
      • sslkey: (optional) entspricht dem Verbindungsparameter sslkey , der den Speicherort des geheimen Schlüssels für das Clientzertifikat angibt.
      • sslpassword: (optional) entspricht dem Verbindungsparameter sslpassword , der das Passwort für den in sslkey angegebenen geheimen Schlüssel festlegt.
      • sslcert: (optional) entspricht dem Verbindungsparameter sslcert , der den Speicherort des Clientzertifikats angibt.
      • sslrootcert: (optional) entspricht dem Verbindungsparameter sslrootcert , der den Pfad zu einer Datei mit einem oder mehreren Zertifikaten von Zertifizierungsstellen (CA) angibt, mit denen der Client ein Serverzertifikat prüft.
      • sslcrl: (optional) entspricht dem Verbindungsparameter sslcrl , der den Pfad zu einer Datei mit einer Zertifikatsperrliste angibt. Ein Client lehnt Verbindungen zu Servern ab, deren Zertifikat in dieser Liste enthalten ist.
      • sslcrldir: (optional) entspricht dem Verbindungsparameter sslcrldir , der den Pfad zu einem Verzeichnis mit Dateien angibt, die eine Zertifikatsperrliste enthalten. Ein Client lehnt Verbindungen zu Servern ab, deren Zertifikat in dieser Liste enthalten ist.
      • sslnegotiation: (optional) entspricht dem Verbindungsparameter sslnegotiation , der steuert, wie die SSL-Verschlüsselung mit dem Server ausgehandelt wird, falls SSL verwendet wird.
      • gssencmode: (optional) entspricht dem Verbindungsparameter gssencmode , der bestimmt, ob und mit welcher Priorität eine sichere GSS-Verbindung über TCP/IP mit dem Server ausgehandelt wird.
      • channel_binding: (optional) entspricht dem Verbindungsparameter channel_binding , der die Verwendung von Channel Binding durch den Client steuert.

  • callbacks: Callback-Skripte, die bei bestimmten Aktionen ausgeführt werden. Patroni übergibt Aktion, Rolle und Clusternamen. (scripts/aws.py zeigt ein Beispiel für solche Skripte.)

    • on_reload: führt dieses Skript aus, wenn das Neuladen der Konfiguration ausgelöst wird.
    • on_restart: führt dieses Skript aus, wenn Postgres neu startet (ohne Rollenwechsel).
    • on_role_change: führt dieses Skript aus, wenn Postgres hoch- oder herabgestuft wird.
    • on_start: führt dieses Skript aus, wenn Postgres startet.
    • on_stop: führt dieses Skript aus, wenn Postgres stoppt.

  • connect_address: IP-Adresse + Port, über die Postgres für andere Knoten und Anwendungen erreichbar ist.

  • proxy_address: IP-Adresse + Port, über die ein neben Postgres laufender Verbindungspool (z. B. PgBouncer) erreichbar ist. Der Wert wird als proxy_url in den Mitgliedsschlüssel im DCS geschrieben und kann für die Diensterkennung verwendet werden beziehungsweise nützlich sein.

  • create_replica_methods: geordnete Liste der Erstellungsmethoden, mit denen ein Patroni-Knoten zu einem neuen Replikat wird. Die Standardmethode ist “basebackup”; andere Methoden verweisen auf Skripte, die jeweils mit einem eigenen Konfigurationseintrag konfiguriert werden. Weitere Erläuterungen enthält die Dokumentation benutzerdefinierter Methoden zur Replikaterstellung .

  • data_dir: Pfad zum Postgres-Datenverzeichnis, das bereits existiert oder von Patroni initialisiert werden soll.

  • config_dir: Pfad zum Postgres-Konfigurationsverzeichnis; standardmäßig das Datenverzeichnis. Es muss für Patroni beschreibbar sein.

  • bin_dir: (optional) Pfad zu den PostgreSQL-Programmdateien (pg_ctl, initdb, pg_controldata, pg_basebackup, postgres, pg_isready, pg_rewind). Ohne Angabe oder bei einer leeren Zeichenfolge werden die Programme über die Umgebungsvariable PATH gesucht.

  • bin_name: (optional) ermöglicht das Überschreiben der Postgres-Programmnamen bei einer benutzerdefinierten Postgres-Distribution:

    • pg_ctl: (optional) benutzerdefinierter Name für die Programmdatei pg_ctl.
    • initdb: (optional) benutzerdefinierter Name für die Programmdatei initdb.
    • pg_controldata: (optional) benutzerdefinierter Name für die Programmdatei pg_controldata.
    • pg_basebackup: (optional) benutzerdefinierter Name für die Programmdatei pg_basebackup.
    • postgres: (optional) benutzerdefinierter Name für die Programmdatei postgres.
    • pg_isready: (optional) benutzerdefinierter Name für die Programmdatei pg_isready.
    • pg_rewind: (optional) benutzerdefinierter Name für die Programmdatei pg_rewind.

  • listen: IP-Adresse + Port, an denen Postgres auf Verbindungen wartet; bei Streaming-Replikation müssen sie von anderen Clusterknoten aus erreichbar sein. Mehrere durch Kommas getrennte Adressen sind zulässig, sofern der Port nach der letzten Adresse mit einem Doppelpunkt angehängt wird, etwa listen: 127.0.0.1,127.0.0.2:5432. Patroni verwendet die erste Adresse dieser Liste, um lokale Verbindungen zum PostgreSQL-Knoten aufzubauen.

  • use_unix_socket: legt fest, dass Patroni für die Verbindung zum Cluster bevorzugt Unix-Sockets verwenden sollte. Standardwert: false. Ist unix_socket_directories definiert, verwendet Patroni daraus den ersten geeigneten Wert für die Verbindung zum Cluster und greift auf TCP zurück, wenn kein Wert geeignet ist. Ist unix_socket_directories nicht in postgresql.parameters angegeben, nimmt Patroni an, dass der Standardwert verwendet werden sollte, und lässt host in den Verbindungsparametern weg.

  • use_unix_socket_repl: legt fest, dass Patroni für die Clusterverbindung des Replikationsbenutzers bevorzugt Unix-Sockets verwenden sollte. Standardwert: false. Ist unix_socket_directories definiert, verwendet Patroni daraus den ersten geeigneten Wert für die Verbindung zum Cluster und greift auf TCP zurück, wenn kein Wert geeignet ist. Ist unix_socket_directories nicht in postgresql.parameters angegeben, nimmt Patroni an, dass der Standardwert verwendet werden sollte, und lässt host in den Verbindungsparametern weg.

  • pgpass: Pfad zur Passwortdatei .pgpass . Patroni erstellt diese Datei vor dem Ausführen von pg_basebackup, des Skripts post_init und in einigen weiteren Fällen. Der Speicherort muss für Patroni beschreibbar sein.

  • recovery_conf: zusätzliche Konfigurationseinstellungen, die beim Konfigurieren eines Followers in recovery.conf geschrieben werden.

  • custom_conf : Pfad zu einer optionalen benutzerdefinierten Datei postgresql.conf, die anstelle von postgresql.base.conf verwendet wird. Sie muss auf allen Clusterknoten existieren, für PostgreSQL lesbar sein und wird von ihrem Speicherort aus in die tatsächliche postgresql.conf eingebunden. Patroni überwacht diese Datei weder auf Änderungen noch erstellt es ein Backup davon. Ihre Einstellungen können dennoch durch Patronis eigene Konfigurationsmöglichkeiten überschrieben werden; Einzelheiten stehen unter Dynamische Konfiguration .

  • parameters: Konfigurationsparameter (GUCs) für Postgres im Format {ssl: "on", ssl_cert_file: "cert_file"}.

  • parameters_primary: (optional) rollenspezifische Parameterüberschreibungen für primary. Diese Werte werden mit den grundlegenden parameters zusammengeführt und überschreiben sie.

  • parameters_replica: (optional) rollenspezifische Parameterüberschreibungen für replica. Diese Werte werden mit den grundlegenden parameters zusammengeführt und überschreiben sie.

  • parameters_standby_leader: (optional) rollenspezifische Parameterüberschreibungen für standby_leader. Diese Werte werden mit den grundlegenden parameters zusammengeführt und überschreiben sie.

  • pg_hba: Liste der Zeilen, aus denen Patroni pg_hba.conf erzeugt. Patroni ignoriert diesen Parameter, wenn der PostgreSQL-Parameter hba_file auf einen anderen Wert als den Standardwert gesetzt ist. Zusammen mit der dynamischen Konfiguration vereinfacht dieser Parameter die Verwaltung von pg_hba.conf.

    • - host all all 0.0.0.0/0 md5
    • - host replication replicator 127.0.0.1/32 md5: Eine solche Zeile ist für die Replikation erforderlich.

  • pg_hba_primary: (optional) rollenspezifische pg_hba-Einträge für primary. Sie ersetzen pg_hba vollständig (keine Zusammenführung). Sind sie nicht definiert, wird pg_hba verwendet.

  • pg_hba_replica: (optional) rollenspezifische pg_hba-Einträge für replica. Sie ersetzen pg_hba vollständig (keine Zusammenführung). Sind sie nicht definiert, wird pg_hba verwendet.

  • pg_hba_standby_leader: (optional) rollenspezifische pg_hba-Einträge für standby_leader. Sie ersetzen pg_hba vollständig (keine Zusammenführung). Sind sie nicht definiert, wird pg_hba verwendet.

  • pg_ident: Liste der Zeilen, aus denen Patroni pg_ident.conf erzeugt. Patroni ignoriert diesen Parameter, wenn der PostgreSQL-Parameter ident_file auf einen anderen Wert als den Standardwert gesetzt ist. Zusammen mit der dynamischen Konfiguration vereinfacht dieser Parameter die Verwaltung von pg_ident.conf.

    • - mapname1 systemname1 pguser1
    • - mapname1 systemname2 pguser2

  • pg_ident_primary: (optional) rollenspezifische pg_ident-Einträge für primary. Sie ersetzen pg_ident vollständig (keine Zusammenführung). Sind sie nicht definiert, wird pg_ident verwendet.

  • pg_ident_replica: (optional) rollenspezifische pg_ident-Einträge für replica. Sie ersetzen pg_ident vollständig (keine Zusammenführung). Sind sie nicht definiert, wird pg_ident verwendet.

  • pg_ident_standby_leader: (optional) rollenspezifische pg_ident-Einträge für standby_leader. Sie ersetzen pg_ident vollständig (keine Zusammenführung). Sind sie nicht definiert, wird pg_ident verwendet.

  • pg_ctl_timeout: Wartezeit für pg_ctl bei start, stop oder restart. Der Standardwert beträgt 60 Sekunden.

  • use_pg_rewind: versucht, pg_rewind auf dem bisherigen Leader zu verwenden, wenn er dem Cluster als Replikat beitritt. Der Cluster muss mit data page checksums (Option --data-checksums für initdb) initialisiert worden sein und/oder wal_log_hints muss auf on gesetzt sein, andernfalls funktioniert pg_rewind nicht.

  • rewind: (optional) benutzerdefinierte Optionen für den Befehl pg_rewind. Sie können als Liste von Zeichenfolgen und/oder Dictionaries mit jeweils einem Schlüssel-Wert-Paar angegeben werden. Zu den nicht zulässigen Optionen gehören: target-pgdata, source-pgdata, source-server, write-recovery-conf, dry-run, restore-target-wal, config-file, no-ensure-shutdown, version und help. Beispiel:

    postgresql:
      rewind:
        - debug
        - progress
        - sync-method: fsync

  • remove_data_directory_on_rewind_failure: ist diese Option aktiviert, entfernt Patroni das PostgreSQL-Datenverzeichnis und erstellt das Replikat neu. Andernfalls versucht es, dem neuen Leader zu folgen. Standardwert: false.

  • remove_data_directory_on_diverged_timelines: Patroni entfernt das PostgreSQL-Datenverzeichnis und erstellt das Replikat neu, wenn es auseinanderlaufende Timelines erkennt und der bisherige Primärserver nicht mit dem Streaming vom neuen Primärserver beginnen kann. Diese Option ist nützlich, wenn pg_rewind nicht verwendet werden kann. Beim Prüfen auf auseinanderlaufende Timelines unter PostgreSQL v10 und älter versucht Patroni, sich mit den Replikationszugangsdaten zur Datenbank “postgres” zu verbinden. Daher sollte dieser Zugriff in pg_hba.conf erlaubt sein. Standardwert: false.

  • replica_method: für jeden Eintrag in create_replica_methods außer basebackup wird ein gleichnamiger Konfigurationsabschnitt hinzugefügt. Er sollte mindestens “command” mit dem vollständigen Pfad zum auszuführenden Skript enthalten. Andere Konfigurationsparameter werden im Format “parameter=value” an das Skript übergeben.

  • pre_promote: Fencing-Skript, das während eines Failovers nach dem Erwerb der Leader-Sperre, aber vor dem Hochstufen des Replikats ausgeführt wird. Endet das Skript mit einem von null verschiedenen Code, stuft Patroni das Replikat nicht hoch und entfernt den Leader-Schlüssel aus dem DCS.

  • before_stop: Skript, das unmittelbar vor dem Stoppen von Postgres ausgeführt wird. Anders als ein Callback läuft dieses Skript synchron und blockiert das Herunterfahren bis zu seinem Abschluss. Sein Rückgabecode beeinflusst nicht, ob das Herunterfahren anschließend fortgesetzt wird.

REST API

• restapi:
  • thread_pool_size: Größe des Threadpools, mit dem Patroni REST-API-Anfragen verarbeitet. Mindestwert: 5, Standardwert: 5.
  • connect_address: IP-Adresse (oder Hostname) und Port für den Zugriff auf die REST API von Patroni. Alle Clustermitglieder müssen diese Adresse erreichen können. Sofern die Patroni-Installation nicht als lokale Demo gedacht ist, darf daher weder “localhost” noch eine Loopback-Adresse (also “localhost” oder “127.0.0.1”) verwendet werden. Die Adresse kann als Endpunkt für HTTP Health Checks (siehe unten den REST-API-Parameter “listen”), für Benutzerabfragen (direkt oder über die REST API) sowie für die Health Checks der Clustermitglieder während der Leader-Wahl dienen (etwa um festzustellen, ob der Leader noch läuft oder ob ein Knoten eine weiter fortgeschrittene WAL-Position hat als der abfragende Knoten). connect_address wird im Mitgliedsschlüssel im DCS gespeichert, sodass sich der Mitgliedsname in die Adresse für den Zugriff auf dessen REST API auflösen lässt.
  • listen: IP-Adresse (oder Hostname) und Port, an denen Patroni für die REST API auf Verbindungen wartet, um die oben beschriebenen Health Checks und die Kommunikation zwischen den beteiligten Clusterknoten bereitzustellen. Dient außerdem zum Bereitstellen von Health-Check-Informationen für HAProxy (oder jeden anderen Load-Balancer, der HTTP-Prüfungen mit “OPTIONS” oder “GET” ausführen kann).
  • authentication: (optional)
    • username: Benutzername für die Basic-Authentifizierung zum Schutz unsicherer REST-API-Endpunkte.
    • password: Passwort für die Basic-Authentifizierung zum Schutz unsicherer REST-API-Endpunkte.
  • certfile: (optional) gibt die Datei mit dem Zertifikat im PEM-Format an. Ist certfile nicht angegeben oder leer, arbeitet der API-Server ohne SSL.
  • keyfile: (optional) gibt die Datei mit dem geheimen Schlüssel im PEM-Format an.
  • keyfile_password: (optional) gibt ein Passwort zum Entschlüsseln der Schlüsseldatei an.
  • cafile: (optional) gibt die Datei mit dem CA_BUNDLE vertrauenswürdiger CA-Zertifikate an, die zum Prüfen der Clientzertifikate verwendet werden.
  • ciphers: (optional) gibt die zulässigen Cipher Suites an (z. B. “ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:!SSLv1:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1”)
  • verify_client: (optional) none (Standard), optional oder required. Bei none prüft die REST API keine Clientzertifikate. Bei required sind Clientzertifikate für alle REST-API-Aufrufe erforderlich. Bei optional sind sie für alle unsicheren REST-API-Endpunkte erforderlich. Bei required ist die Clientauthentifizierung erfolgreich, wenn die Prüfung der Zertifikatssignatur erfolgreich ist. Bei optional wird das Clientzertifikat nur bei Anfragen mit PUT, POST, PATCH und DELETE geprüft.
  • allowlist: (optional): legt die Hosts fest, die unsichere REST-API-Endpunkte aufrufen dürfen. Ein Eintrag kann ein Hostname, eine IP-Adresse oder eine Netzwerkadresse in CIDR-Schreibweise sein. Standardmäßig gilt allow all. Ist allowlist oder allowlist_include_members gesetzt, werden alle nicht enthaltenen Zugriffe abgelehnt.
  • allowlist_include_members: (optional): bei true dürfen andere im DCS registrierte Clustermitglieder auf unsichere REST-API-Endpunkte zugreifen (IP-Adresse oder Hostname werden aus api_url des Mitglieds übernommen). Vorsicht: Das Betriebssystem kann für ausgehende Verbindungen eine andere IP-Adresse verwenden.
  • http_extra_headers: (optional) HTTP-Header ermöglichen es dem REST-API-Server, zusätzliche Informationen mit einer HTTP-Antwort zu übertragen.
  • https_extra_headers: (optional) HTTPS-Header ermöglichen es dem REST-API-Server, bei aktiviertem TLS zusätzliche Informationen mit einer HTTP-Antwort zu übertragen. Die in http_extra_headers festgelegten Zusatzinformationen werden ebenfalls übertragen.
  • request_queue_size: (optional): legt die Größe der Anfragewarteschlange für den TCP-Socket der Patroni REST API fest. Ist die Warteschlange voll, erhalten weitere Anfragen den Fehler “Connection denied”. Der Standardwert ist 5.
  • server_tokens: (optional): konfiguriert den Wert des HTTP-Headers Server.
    • Minimal: Der Header enthält nur die Patroni-Version, etwa Patroni/4.0.0.
    • ProductOnly: Der Header enthält nur den Produktnamen, etwa Patroni.
    • Original (Standard): Der Header behält das ursprüngliche Verhalten bei und zeigt die Versionen von BaseHTTP und Python an, etwa BaseHTTP/0.6 Python/3.12.3.

Hier ein Beispiel für http_extra_headers und https_extra_headers:

restapi:
  listen: <listen>
  connect_address: <connect_address>
  authentication:
    username: <username>
    password: <password>
  http_extra_headers:
    'X-Frame-Options': 'SAMEORIGIN'
    'X-XSS-Protection': '1; mode=block'
    'X-Content-Type-Options': 'nosniff'
  cafile: <ca file>
  certfile: <cert>
  keyfile: <key>
  https_extra_headers:
    'Strict-Transport-Security': 'max-age=31536000; includeSubDomains'

CTL

• ctl: (optional)
  • authentication:
    • username: Benutzername für die Basic-Authentifizierung beim Zugriff auf geschützte REST-API-Endpunkte. Ohne Angabe verwendet patronictl den Wert des REST-API-Parameters “username”.
    • password: Passwort für die Basic-Authentifizierung beim Zugriff auf geschützte REST-API-Endpunkte. Ohne Angabe verwendet patronictl den Wert des REST-API-Parameters “password”.
  • insecure: erlaubt Verbindungen zur REST API ohne Prüfung der SSL-Zertifikate.
  • cacert: gibt die CA_BUNDLE-Datei oder das Verzeichnis mit Zertifikaten vertrauenswürdiger CAs an, die zum Prüfen der SSL-Zertifikate der REST API verwendet werden. Ohne Angabe verwendet patronictl den Wert des REST-API-Parameters “cafile”.
  • certfile: gibt die Datei mit dem Clientzertifikat im PEM-Format an.
  • keyfile: gibt die Datei mit dem geheimen Clientschlüssel im PEM-Format an.
  • keyfile_password: gibt ein Passwort zum Entschlüsseln der Clientschlüsseldatei an.

Watchdog

• mode: off, automatic oder required. Bei off ist der Watchdog deaktiviert. Bei automatic wird er verwendet, falls verfügbar, andernfalls ignoriert. Bei required wird der Knoten nur dann Leader, wenn der Watchdog erfolgreich aktiviert werden kann.
• device: Pfad zum Watchdog-Gerät. Standardwert: /dev/watchdog.
• safety_margin: Sicherheitsabstand in Sekunden zwischen dem Auslösen des Watchdogs und dem Ablauf des Leader-Schlüssels.

Tags

• clonefrom: true oder false. Bei true bevorzugen andere Knoten möglicherweise diesen Knoten zur Initialisierung (als Quelle für pg_basebackup). Haben mehrere Knoten das Tag clonefrom auf true gesetzt, wird die Quelle für die Initialisierung zufällig ausgewählt. Standardwert: false.
• noloadbalance: true oder false. Bei true antwortet der Knoten auf den REST-API-Health-Check GET /replica mit HTTP-Statuscode 503 und wird dadurch von der Lastverteilung ausgeschlossen. Standardwert: false.
• replicatefrom: Name eines anderen Replikats, von dem repliziert werden soll. Dient zur Unterstützung kaskadierender Replikation.
• nosync: true oder false. Bei true wird der Knoten niemals als synchrones Replikat ausgewählt.
• sync_priority: Ganzzahl, die die Priorität dieses Knotens bei der Auswahl synchroner Replikate bestimmt, wenn synchronous_mode auf on gesetzt ist. Knoten mit höherer Priorität werden gegenüber solchen mit niedrigerer Priorität bevorzugt. Ist sync_priority 0 oder negativ, darf dieser Knoten nicht in den PostgreSQL-Parameter synchronous_standby_names aufgenommen werden (wie bei nosync: true). Beachten Sie, dass dieser Parameter die entgegengesetzte Bedeutung zum Wert sync_priority in der Sicht pg_stat_replication hat.
• nofailover: true oder false; steuert, ob dieser Knoten an der Leader-Wahl teilnehmen und Leader werden darf. Standardwert: false, das heißt, dieser Knoten darf_ an Leader-Wahlen teilnehmen.
• failover_priority: Ganzzahl, die die Priorität dieses Knotens bei einem Failover bestimmt. Knoten mit höherer Priorität werden gegenüber solchen mit niedrigerer Priorität bevorzugt, wenn sie dieselbe Menge WAL empfangen beziehungsweise wiedergegeben haben. Knoten mit höherer Empfangs-/Wiedergabe-LSN werden jedoch unabhängig von ihrer Priorität bevorzugt. Ist failover_priority 0 oder negativ, darf dieser Knoten weder an der Leader-Wahl teilnehmen noch Leader werden (wie bei nofailover: true). Bekannte Einschränkung: failover_priority funktioniert derzeit nicht mit Quorum-basierter synchroner Replikation .
• nostream: true oder false. Bei true verwendet der Knoten nicht das Replikationsprotokoll zum Streamen von WAL. Stattdessen nutzt er Archiv-Recovery (falls restore_command konfiguriert ist) und fragt pg_wal/pg_xlog regelmäßig ab. Dies deaktiviert außerdem das Kopieren und Synchronisieren permanenter logischer Replikationsslots auf dem Knoten selbst und allen seinen kaskadierenden Replikaten. Auf einem Primärserver hat dieses Tag keine Wirkung.

Neben diesen vordefinierten Tags können auch eigene hinzugefügt werden:

• key1: true
• key2: false
• key3: 1.4
• key4: "RandomString"

Tags sind in der REST API und in patronictl_list sichtbar. Mit diesen Tags lässt sich auch die Funktionsfähigkeit einer Instanz prüfen. Ist das Tag für eine Instanz nicht definiert oder stimmt sein Wert nicht mit dem abgefragten Wert überein, wird HTTP-Statuscode 503 zurückgegeben.

3 - Umgebungskonfiguration

Einige in der Patroni-Konfigurationsdatei definierte Parameter können über Systemumgebungsvariablen überschrieben werden. Dieses Dokument listet alle von Patroni verarbeiteten Umgebungsvariablen auf. Die über diese Variablen gesetzten Werte haben stets Vorrang vor den Werten in der Patroni-Konfigurationsdatei.

Global/Allgemein

• PATRONI_CONFIGURATION: die gesamte Patroni-Konfiguration kann über die Umgebungsvariable PATRONI_CONFIGURATION festgelegt werden. In diesem Fall werden alle anderen Umgebungsvariablen ignoriert!
• PATRONI_THREAD_POOL_SIZE: Größe des Threadpools, mit dem Patroni asynchrone Aufgaben ausführt und während der Leader-Wahl oder bei Failsafe-Prüfungen über die REST API mit anderen Mitgliedern kommuniziert. Mindestwert: 5, Standardwert: 5.
• PATRONI_THREAD_STACK_SIZE: legt die Stackgröße für von Patroni gestartete Threads fest. Der Wert muss an 64kB ausgerichtet sein. Mindestwert: 64kB, Standardwert (von Patroni gesetzt): 512kB.
• PATRONI_NAME: Name des Knotens, auf dem die aktuelle Patroni-Instanz läuft. Er muss im Cluster eindeutig sein.
• PATRONI_NAMESPACE: Pfad im Konfigurationsspeicher, unter dem Patroni Informationen über den Cluster speichert. Standardwert: “/service”
• PATRONI_SCOPE: Clustername
• PG_MALLOC_ARENA_MAX: benutzerdefinierter Wert für die Umgebungsvariable MALLOC_ARENA_MAX des Prozesses postmaster. Ist er nicht gesetzt, erbt postmaster den Wert von MALLOC_ARENA_MAX.

Protokollierung

• PATRONI_LOG_TYPE: legt das Protokollformat fest. Mögliche Werte sind plain und json. Für das Format json muss jsonlogger installiert sein. Der Standardwert ist plain.
• PATRONI_LOG_LEVEL: legt die allgemeine Protokollierungsstufe fest. Standardwert: INFO (siehe Dokumentation der Python-Protokollierung )
• PATRONI_LOG_TRACEBACK_LEVEL: legt die Stufe fest, auf der Tracebacks sichtbar sind. Standardwert: ERROR. Auf DEBUG setzen, wenn Tracebacks nur bei aktiviertem PATRONI_LOG_LEVEL=DEBUG sichtbar sein sollen.
• PATRONI_LOG_FORMAT: legt die Formatzeichenfolge für Protokolle fest. Beim Protokolltyp plain sollte das Format eine Zeichenfolge sein. Verfügbare Attribute stehen unter LogRecord-Attribute . Beim Protokolltyp json kann das Format neben einer Zeichenfolge auch eine Liste sein. Jeder Listeneintrag sollte einem LogRecord-Attribut entsprechen. Dabei wird nur der Feldname benötigt; %( und ) sollten weggelassen werden. Um ein Protokollfeld unter einem anderen Schlüsselnamen auszugeben, ein Dictionary verwenden: Der Schlüssel bezeichnet das Protokollfeld, der Wert den im Protokoll auszugebenden Feldnamen. Standardwert: %(asctime)s %(levelname)s: %(message)s
• PATRONI_LOG_DATEFORMAT: legt die Formatzeichenfolge für Datum und Uhrzeit fest (siehe Dokumentation zu formatTime() ).
• PATRONI_LOG_STATIC_FIELDS: fügt dem Protokoll zusätzliche Felder hinzu. Diese Option ist nur beim Protokolltyp json verfügbar. Beispiel: PATRONI_LOG_STATIC_FIELDS="{app: patroni}"
• PATRONI_LOG_MAX_QUEUE_SIZE: Patroni verwendet eine zweistufige Protokollierung. Protokolleinträge werden in eine Warteschlange im Arbeitsspeicher geschrieben; ein separater Thread entnimmt sie und schreibt sie nach stderr oder in eine Datei. Die interne Warteschlange ist standardmäßig auf 1000 Einträge begrenzt, was für die Protokolle der letzten 1h20m ausreicht.
• PATRONI_LOG_DIR: Verzeichnis für die Anwendungsprotokolle. Es muss existieren und für den Benutzer, der Patroni ausführt, beschreibbar sein. Ist diese Umgebungsvariable gesetzt, bewahrt die Anwendung standardmäßig 4 Protokolldateien mit jeweils 25MB auf. Diese Aufbewahrungswerte lassen sich mit PATRONI_LOG_FILE_NUM und PATRONI_LOG_FILE_SIZE anpassen (siehe unten).
• PATRONI_LOG_MODE: Berechtigungen für Protokolldateien (z. B. 0644). Ohne Angabe werden die Berechtigungen anhand des aktuellen umask-Werts gesetzt.
• PATRONI_LOG_FILE_NUM: Anzahl der aufzubewahrenden Anwendungsprotokolle.
• PATRONI_LOG_FILE_SIZE: Größe der Datei patroni.log (in Bytes), bei der eine Protokollrotation ausgelöst wird.
• PATRONI_LOG_LOGGERS: definiert die Protokollierungsstufe je Python-Modul neu. Beispiel: PATRONI_LOG_LOGGERS="{patroni.postmaster: WARNING, urllib3: DEBUG}"
• PATRONI_LOG_DEDUPLICATE_HEARTBEAT_LOGS: bei true werden aufeinanderfolgende identische Heartbeat-Protokolleinträge nicht ausgegeben. Standardwert: false.

Citus

Aktiviert die Integration von Patroni mit Citus . Ist sie konfiguriert, übernimmt Patroni die Registrierung der Citus-Worker-Knoten beim Coordinator. Weitere Informationen zur Citus-Unterstützung stehen hier .

• PATRONI_CITUS_GROUP: Citus-Gruppen-ID als Ganzzahl. Für den Coordinator 0 verwenden, für Worker 1, 2 usw.
• PATRONI_CITUS_DATABASE: Datenbank, in der die Erweiterung citus erstellt werden sollte. Sie muss auf dem Coordinator und allen Workern identisch sein. Derzeit wird nur eine Datenbank unterstützt.

Consul

• PATRONI_CONSUL_HOST: host:port des lokalen Consul-Agenten.
• PATRONI_CONSUL_URL: URL des lokalen Consul-Agenten im Format: http(s)://host:port
• PATRONI_CONSUL_PORT: (optional) Consul-Port
• PATRONI_CONSUL_SCHEME: (optional) http oder https, Standardwert http
• PATRONI_CONSUL_TOKEN: (optional) ACL-Token
• PATRONI_CONSUL_VERIFY: (optional) bestimmt, ob das SSL-Zertifikat bei HTTPS-Anfragen geprüft wird
• PATRONI_CONSUL_CACERT: (optional) CA-Zertifikat. Falls vorhanden, wird die Validierung aktiviert.
• PATRONI_CONSUL_CERT: (optional) Datei mit dem Clientzertifikat
• PATRONI_CONSUL_KEY: (optional) Datei mit dem Clientschlüssel. Kann leer sein, wenn der Schlüssel Bestandteil des Zertifikats ist.
• PATRONI_CONSUL_DC: (optional) Rechenzentrum, mit dem kommuniziert werden soll. Standardmäßig wird das Rechenzentrum des Hosts verwendet.
• PATRONI_CONSUL_CONSISTENCY: (optional) wählt den Konsistenzmodus von Consul. Mögliche Werte: default, consistent oder stale (Einzelheiten in der Consul-API-Referenz )
• PATRONI_CONSUL_CHECKS: (optional) Liste der für die Sitzung verwendeten Consul Health Checks. Standardmäßig wird eine leere Liste verwendet.
• PATRONI_CONSUL_REGISTER_SERVICE: (optional) bestimmt, ob ein Dienst registriert wird, dessen Name durch den Parameter scope festgelegt ist und der je nach Knotenrolle das Tag master, primary, replica oder standby-leader erhält. Standardwert false
• PATRONI_CONSUL_SERVICE_TAGS: (optional) zusätzliche statische Tags für den Consul-Dienst neben der Rolle (primary/replica/standby-leader). Standardmäßig wird eine leere Liste verwendet.
• PATRONI_CONSUL_SERVICE_CHECK_INTERVAL: (optional) Häufigkeit der Health Checks für die registrierte URL
• PATRONI_CONSUL_SERVICE_CHECK_TLS_SERVER_NAME: (optional) überschreibt den SNI-Host bei TLS-Verbindungen; siehe auch die API-Referenz für Consul-Agent-Prüfungen .

etcd

• PATRONI_ETCD_PROXY: Proxy-URL für etcd. Bei einer Verbindung zu etcd über einen Proxy diesen Parameter anstelle von PATRONI_ETCD_URL verwenden.
• PATRONI_ETCD_URL: URL für etcd im Format: http(s)://(username:password@)host:port
• PATRONI_ETCD_HOSTS: Liste der etcd-Endpunkte im Format ‘host1:port1’,‘host2:port2’,etc…
• PATRONI_ETCD_USE_PROXIES: ist dieser Parameter auf true gesetzt, behandelt Patroni hosts als Liste von Proxys und ermittelt nicht die Topologie des etcd-Clusters, sondern bleibt bei der festen Liste hosts.
• PATRONI_ETCD_PROTOCOL: http oder https; ohne Angabe wird http verwendet. Ist url oder proxy angegeben, wird das Protokoll daraus übernommen.
• PATRONI_ETCD_HOST: host:port des etcd-Endpunkts.
• PATRONI_ETCD_SRV: Domain, in der nach SRV-Einträgen für die automatische Clustererkennung gesucht wird. Patroni fragt für die angegebene Domain diese SRV-Dienstnamen ab (in dieser Reihenfolge bis zum ersten Erfolg): _etcd-client-ssl, _etcd-client, _etcd-ssl, _etcd, _etcd-server-ssl, _etcd-server. Werden SRV-Einträge für _etcd-server-ssl oder _etcd-server gefunden, wird über das ETCD-Peer-Protokoll bei ETCD nach verfügbaren Mitgliedern gefragt. Andernfalls werden die Hosts aus den SRV-Einträgen verwendet.
• PATRONI_ETCD_SRV_SUFFIX: konfiguriert ein Suffix für den bei der Erkennung abgefragten SRV-Namen. Mit diesem Flag lassen sich mehrere etcd-Cluster unter derselben Domain unterscheiden. Es funktioniert nur zusammen mit PATRONI_ETCD_SRV. Sind beispielsweise PATRONI_ETCD_SRV_SUFFIX=foo und PATRONI_ETCD_SRV=example.org gesetzt, wird folgende DNS-SRV-Abfrage ausgeführt: _etcd-client-ssl-foo._tcp.example.org (entsprechend für jeden möglichen ETCD-SRV-Dienstnamen).
• PATRONI_ETCD_USERNAME: Benutzername für die etcd-Authentifizierung.
• PATRONI_ETCD_PASSWORD: Passwort für die etcd-Authentifizierung.
• PATRONI_ETCD_CACERT: CA-Zertifikat. Falls vorhanden, wird die Validierung aktiviert.
• PATRONI_ETCD_CERT: Datei mit dem Clientzertifikat.
• PATRONI_ETCD_KEY: Datei mit dem Clientschlüssel. Kann leer sein, wenn der Schlüssel Bestandteil des Zertifikats ist.

Etcdv3

Die Namen der Umgebungsvariablen für Etcdv3 entsprechen denen für etcd; im Variablennamen muss lediglich ETCD durch ETCD3 ersetzt werden. Beispiele: PATRONI_ETCD3_HOST, PATRONI_ETCD3_CACERT usw.

ZooKeeper

• PATRONI_ZOOKEEPER_HOSTS: durch Kommas getrennte Liste der ZooKeeper-Clustermitglieder: “‘host1:port1’,‘host2:port2’,’etc…’”. Jeder einzelne Eintrag muss in Anführungszeichen stehen!
• PATRONI_ZOOKEEPER_USE_SSL: (optional) bestimmt, ob SSL verwendet wird. Standardwert: false. Bei false werden alle SSL-spezifischen Parameter ignoriert.
• PATRONI_ZOOKEEPER_CACERT: (optional) CA-Zertifikat. Falls vorhanden, wird die Validierung aktiviert.
• PATRONI_ZOOKEEPER_CERT: (optional) Datei mit dem Clientzertifikat.
• PATRONI_ZOOKEEPER_KEY: (optional) Datei mit dem Clientschlüssel.
• PATRONI_ZOOKEEPER_KEY_PASSWORD: (optional) Passwort für den Clientschlüssel.
• PATRONI_ZOOKEEPER_VERIFY: (optional) bestimmt, ob das Zertifikat geprüft wird. Standardwert: true.
• PATRONI_ZOOKEEPER_SET_ACLS: (optional) falls gesetzt, wird Kazoo so konfiguriert, dass es auf jeden neu erstellten ZNode eine Standard-ACL anwendet. ACLs können das Schema x509 (Standard) oder andere unterstützte ZooKeeper-Schemata wie digest verwenden. Sie sollten als Dictionary angegeben werden, dessen Schlüssel der vollständige Principal (optional mit vorangestelltem Schema) und dessen Wert eine Liste von Berechtigungen ist. Als Berechtigungen sind eine oder mehrere aus CREATE, READ, WRITE, DELETE, ADMIN oder ALL möglich. Beispiel: set_acls: {CN=principal1: [CREATE, READ], digest:principal2:+pjROuBuuwNNSujKyH8dGcEnFPQ=: [ALL]}.
• PATRONI_ZOOKEEPER_AUTH_DATA: (optional) Zugangsdaten für die Verbindung. Sollte ein Dictionary mit scheme als Schlüssel und credential als Wert sein. Standardwert ist ein leeres Dictionary.

Exhibitor

• PATRONI_EXHIBITOR_HOSTS: anfängliche Liste der Exhibitor-Knoten (ZooKeeper) im Format: ‘host1,host2,etc…’. Diese Liste wird bei jeder Änderung der Topologie des Exhibitor-Clusters (ZooKeeper) automatisch aktualisiert.
• PATRONI_EXHIBITOR_PORT: Exhibitor-Port.

Kubernetes

• PATRONI_KUBERNETES_BYPASS_API_SERVICE: (optional) bei der Kommunikation mit der Kubernetes API verwendet Patroni normalerweise den Dienst kubernetes , dessen Adresse den Pods über die Umgebungsvariable KUBERNETES_SERVICE_HOST bereitgestellt wird. Ist PATRONI_KUBERNETES_BYPASS_API_SERVICE auf true gesetzt, ermittelt Patroni die Liste der API-Knoten hinter dem Dienst und verbindet sich direkt mit ihnen.
• PATRONI_KUBERNETES_NAMESPACE: (optional) Kubernetes-Namespace, in dem der Patroni-Pod läuft. Standardwert: default.
• PATRONI_KUBERNETES_LABELS: Labels im Format {label1: value1, label2: value2}. Mit diesen Labels werden vorhandene Objekte (Pods sowie Endpoints oder ConfigMaps) gesucht, die zum aktuellen Cluster gehören. Außerdem setzt Patroni sie auf jedem von ihm erstellten Objekt (Endpoint oder ConfigMap).
• PATRONI_KUBERNETES_SCOPE_LABEL: (optional) Name des Labels mit dem Clusternamen. Standardwert: cluster-name.
• PATRONI_KUBERNETES_BOOTSTRAP_LABELS: (optional) Labels im Format {label1: value1, label2: value2}. Sie werden einem Patroni-Pod zugewiesen, wenn sein Zustand initializing new cluster, running custom bootstrap script, starting after custom bootstrap oder creating replica ist.
• PATRONI_KUBERNETES_ROLE_LABEL: (optional) Name des Labels mit der Rolle (primary, replica oder ein anderer benutzerdefinierter Wert). Patroni setzt dieses Label auf dem Pod, in dem es läuft. Standardwert: role.
• PATRONI_KUBERNETES_LEADER_LABEL_VALUE: (optional) Wert des Pod-Labels, wenn die Postgres-Rolle primary ist. Standardwert: primary.
• PATRONI_KUBERNETES_FOLLOWER_LABEL_VALUE: (optional) Wert des Pod-Labels, wenn die Postgres-Rolle replica ist. Standardwert: replica.
• PATRONI_KUBERNETES_STANDBY_LEADER_LABEL_VALUE: (optional) Wert des Pod-Labels, wenn die Postgres-Rolle standby_leader ist. Standardwert: primary.
• PATRONI_KUBERNETES_TMP_ROLE_LABEL: (optional) Name des temporären Labels mit der Rolle (primary oder replica). Der Wert dieses Labels entspricht immer dem Standardwert der jeweiligen Rolle. Nur bei Bedarf setzen.
• PATRONI_KUBERNETES_USE_ENDPOINTS: (optional) bei true verwendet Patroni Endpoints anstelle von ConfigMaps für die Leader-Wahl und zum Speichern des Clusterzustands.
• PATRONI_KUBERNETES_POD_IP: (optional) IP-Adresse des Pods, in dem Patroni läuft. Dieser Wert ist erforderlich, wenn PATRONI_KUBERNETES_USE_ENDPOINTS aktiviert ist, und wird beim Hochstufen von PostgreSQL im Pod zum Befüllen der Subsets des Leader-Endpoints verwendet.
• PATRONI_KUBERNETES_PORTS: (optional) enthält das Service-Objekt einen Namen für den Port, muss derselbe Name im Endpoint-Objekt erscheinen; andernfalls funktioniert der Dienst nicht. Ist der Dienst beispielsweise als {Kind: Service, spec: {ports: [{name: postgresql, port: 5432, targetPort: 5432}]}} definiert, muss PATRONI_KUBERNETES_PORTS='[{"name": "postgresql", "port": 5432}]' gesetzt werden. Patroni verwendet dies zum Aktualisieren der Subsets des Leader-Endpoints. Dieser Parameter wird nur verwendet, wenn PATRONI_KUBERNETES_USE_ENDPOINTS gesetzt ist.
• PATRONI_KUBERNETES_CACERT: (optional) gibt die CA_BUNDLE-Datei mit den Zertifikaten vertrauenswürdiger CAs an, die zum Prüfen der SSL-Zertifikate der Kubernetes API verwendet werden. Ohne Angabe verwendet Patroni den Wert aus dem ServiceAccount-Secret.
• PATRONI_RETRIABLE_HTTP_CODES: (optional) Liste der HTTP-Statuscodes der K8s API, bei denen ein erneuter Versuch erfolgt. Standardmäßig wiederholt Patroni die Anfrage bei 500, 503 und 504 oder wenn die Antwort der K8s API den HTTP-Header retry-after enthält.

Raft (veraltet)

• PATRONI_RAFT_SELF_ADDR: ip:port, an dem auf Raft-Verbindungen gewartet wird. self_addr muss von anderen Clusterknoten aus erreichbar sein. Ohne Angabe nimmt der Knoten nicht am Konsens teil.
• PATRONI_RAFT_BIND_ADDR: (optional) ip:port, an dem auf Raft-Verbindungen gewartet wird. Ohne Angabe wird self_addr verwendet.
• PATRONI_RAFT_PARTNER_ADDRS: Liste der anderen Patroni-Knoten im Cluster im Format "'ip1:port1','ip2:port2'". Jeder einzelne Eintrag muss in Anführungszeichen stehen!
• PATRONI_RAFT_DATA_DIR: Verzeichnis zum Speichern des Raft-Logs und des Snapshots. Ohne Angabe wird das aktuelle Arbeitsverzeichnis verwendet.
• PATRONI_RAFT_PASSWORD: (optional) verschlüsselt den Raft-Datenverkehr mit dem angegebenen Passwort; erfordert das Python-Modul cryptography.
• PATRONI_RAFT_MIN_TIMEOUT: (optional) minimale Zeitüberschreitung für Wahlen in der zugrunde liegenden Raft-Implementierung pysyncobj, in Sekunden. Muss größer als 3 * PATRONI_RAFT_APPEND_ENTRIES_PERIOD sein. Standardwert: 0.4.
• PATRONI_RAFT_MAX_TIMEOUT: (optional) maximale Zeitüberschreitung für Wahlen in der zugrunde liegenden Raft-Implementierung pysyncobj, in Sekunden. Muss größer als PATRONI_RAFT_MIN_TIMEOUT sein. Standardwert: 1.4.
• PATRONI_RAFT_CONNECTION_TIMEOUT: (optional) Zeit in Sekunden, nach der eine Verbindung ohne Datenempfang als unterbrochen gilt. Muss größer oder gleich PATRONI_RAFT_MAX_TIMEOUT sein. Standardwert: 3.5.
• PATRONI_RAFT_APPEND_ENTRIES_PERIOD: (optional) Intervall in Sekunden zum Senden von Heartbeat-Befehlen. Muss kleiner als ein Drittel von PATRONI_RAFT_MIN_TIMEOUT sein. Standardwert: 0.1.
• PATRONI_RAFT_CONNECTION_RETRY_TIME: (optional) Intervall in Sekunden zwischen erneuten Verbindungsversuchen zu nicht erreichbaren Knoten. Standardwert: 5.0.
• PATRONI_RAFT_LEADER_FALLBACK_TIMEOUT: (optional) Zeit in Sekunden, nach der ein Leader ohne Antwort von der Mehrheit in den Follower-Zustand zurückkehrt. Muss größer als PATRONI_RAFT_APPEND_ENTRIES_PERIOD sein. Standardwert: 30.0.

PostgreSQL

• PATRONI_POSTGRESQL_LISTEN: IP-Adresse + Port, an denen Postgres auf Verbindungen wartet. Mehrere durch Kommas getrennte Adressen sind zulässig, sofern der Port nach der letzten Adresse mit einem Doppelpunkt angehängt wird, etwa listen: 127.0.0.1,127.0.0.2:5432. Patroni verwendet die erste Adresse dieser Liste, um lokale Verbindungen zum PostgreSQL-Knoten aufzubauen.
• PATRONI_POSTGRESQL_CONNECT_ADDRESS: IP-Adresse + Port, über die Postgres für andere Knoten und Anwendungen erreichbar ist.
• PATRONI_POSTGRESQL_PROXY_ADDRESS: IP-Adresse + Port, über die ein neben Postgres laufender Verbindungspool (z. B. PgBouncer) erreichbar ist. Der Wert wird als proxy_url in den Mitgliedsschlüssel im DCS geschrieben und kann für die Diensterkennung verwendet werden beziehungsweise nützlich sein.
• PATRONI_POSTGRESQL_DATA_DIR: Pfad zum Postgres-Datenverzeichnis, das bereits existiert oder von Patroni initialisiert werden soll.
• PATRONI_POSTGRESQL_CONFIG_DIR: Pfad zum Postgres-Konfigurationsverzeichnis; standardmäßig das Datenverzeichnis. Es muss für Patroni beschreibbar sein.
• PATRONI_POSTGRESQL_BIN_DIR: Pfad zu den PostgreSQL-Programmdateien (pg_ctl, initdb, pg_controldata, pg_basebackup, postgres, pg_isready, pg_rewind). Der Standardwert ist eine leere Zeichenfolge; dann werden die Programme über die Umgebungsvariable PATH gesucht.
• PATRONI_POSTGRESQL_BIN_PG_CTL: (optional) benutzerdefinierter Name für die Programmdatei pg_ctl.
• PATRONI_POSTGRESQL_BIN_INITDB: (optional) benutzerdefinierter Name für die Programmdatei initdb.
• PATRONI_POSTGRESQL_BIN_PG_CONTROLDATA: (optional) benutzerdefinierter Name für die Programmdatei pg_controldata.
• PATRONI_POSTGRESQL_BIN_PG_BASEBACKUP: (optional) benutzerdefinierter Name für die Programmdatei pg_basebackup.
• PATRONI_POSTGRESQL_BIN_POSTGRES: (optional) benutzerdefinierter Name für die Programmdatei postgres.
• PATRONI_POSTGRESQL_BIN_IS_READY: (optional) benutzerdefinierter Name für die Programmdatei pg_isready.
• PATRONI_POSTGRESQL_BIN_PG_REWIND: (optional) benutzerdefinierter Name für die Programmdatei pg_rewind.
• PATRONI_POSTGRESQL_PGPASS: Pfad zur Passwortdatei .pgpass . Patroni erstellt diese Datei vor dem Ausführen von pg_basebackup und in einigen weiteren Fällen. Der Speicherort muss für Patroni beschreibbar sein.
• PATRONI_REPLICATION_USERNAME: Benutzername für die Replikation; der Benutzer wird bei der Initialisierung erstellt. Replikate verwenden ihn, um per Streaming-Replikation auf die Replikationsquelle zuzugreifen.
• PATRONI_REPLICATION_PASSWORD: Passwort für die Replikation; der Benutzer wird bei der Initialisierung erstellt.
• PATRONI_REPLICATION_SSLMODE: (optional) entspricht dem Verbindungsparameter sslmode , der dem Client die Auswahl des Modus für die TLS-Aushandlung mit dem Server erlaubt. Einzelheiten zur Funktionsweise der einzelnen Modi stehen in der PostgreSQL-Dokumentation . Der Standardmodus ist prefer.
• PATRONI_REPLICATION_SSLKEY: (optional) entspricht dem Verbindungsparameter sslkey , der den Speicherort des geheimen Schlüssels für das Clientzertifikat angibt.
• PATRONI_REPLICATION_SSLPASSWORD: (optional) entspricht dem Verbindungsparameter sslpassword , der das Passwort für den in PATRONI_REPLICATION_SSLKEY angegebenen geheimen Schlüssel festlegt.
• PATRONI_REPLICATION_SSLCERT: (optional) entspricht dem Verbindungsparameter sslcert , der den Speicherort des Clientzertifikats angibt.
• PATRONI_REPLICATION_SSLROOTCERT: (optional) entspricht dem Verbindungsparameter sslrootcert , der den Pfad zu einer Datei mit einem oder mehreren Zertifikaten von Zertifizierungsstellen (CA) angibt, mit denen der Client ein Serverzertifikat prüft.
• PATRONI_REPLICATION_SSLCRL: (optional) entspricht dem Verbindungsparameter sslcrl , der den Pfad zu einer Datei mit einer Zertifikatsperrliste angibt. Ein Client lehnt Verbindungen zu Servern ab, deren Zertifikat in dieser Liste enthalten ist.
• PATRONI_REPLICATION_SSLCRLDIR: (optional) entspricht dem Verbindungsparameter sslcrldir , der den Pfad zu einem Verzeichnis mit Dateien angibt, die eine Zertifikatsperrliste enthalten. Ein Client lehnt Verbindungen zu Servern ab, deren Zertifikat in dieser Liste enthalten ist.
• PATRONI_REPLICATION_SSLNEGOTIATION: (optional) entspricht dem Verbindungsparameter sslnegotiation , der steuert, wie die SSL-Verschlüsselung mit dem Server ausgehandelt wird, falls SSL verwendet wird.
• PATRONI_REPLICATION_GSSENCMODE: (optional) entspricht dem Verbindungsparameter gssencmode , der bestimmt, ob und mit welcher Priorität eine sichere GSS-Verbindung über TCP/IP mit dem Server ausgehandelt wird.
• PATRONI_REPLICATION_CHANNEL_BINDING: (optional) entspricht dem Verbindungsparameter channel_binding , der die Verwendung von Channel Binding durch den Client steuert.
• PATRONI_SUPERUSER_USERNAME: Name des Superusers, der bei der Initialisierung (initdb) festgelegt und später von Patroni für Verbindungen zu Postgres verwendet wird. Auch pg_rewind verwendet diesen Benutzer.
• PATRONI_SUPERUSER_PASSWORD: Passwort des Superusers, das bei der Initialisierung (initdb) festgelegt wird.
• PATRONI_SUPERUSER_SSLMODE: (optional) entspricht dem Verbindungsparameter sslmode , der dem Client die Auswahl des Modus für die TLS-Aushandlung mit dem Server erlaubt. Einzelheiten zur Funktionsweise der einzelnen Modi stehen in der PostgreSQL-Dokumentation . Der Standardmodus ist prefer.
• PATRONI_SUPERUSER_SSLKEY: (optional) entspricht dem Verbindungsparameter sslkey , der den Speicherort des geheimen Schlüssels für das Clientzertifikat angibt.
• PATRONI_SUPERUSER_SSLPASSWORD: (optional) entspricht dem Verbindungsparameter sslpassword , der das Passwort für den in PATRONI_SUPERUSER_SSLKEY angegebenen geheimen Schlüssel festlegt.
• PATRONI_SUPERUSER_SSLCERT: (optional) entspricht dem Verbindungsparameter sslcert , der den Speicherort des Clientzertifikats angibt.
• PATRONI_SUPERUSER_SSLROOTCERT: (optional) entspricht dem Verbindungsparameter sslrootcert , der den Pfad zu einer Datei mit einem oder mehreren Zertifikaten von Zertifizierungsstellen (CA) angibt, mit denen der Client ein Serverzertifikat prüft.
• PATRONI_SUPERUSER_SSLCRL: (optional) entspricht dem Verbindungsparameter sslcrl , der den Pfad zu einer Datei mit einer Zertifikatsperrliste angibt. Ein Client lehnt Verbindungen zu Servern ab, deren Zertifikat in dieser Liste enthalten ist.
• PATRONI_SUPERUSER_SSLCRLDIR: (optional) entspricht dem Verbindungsparameter sslcrldir , der den Pfad zu einem Verzeichnis mit Dateien angibt, die eine Zertifikatsperrliste enthalten. Ein Client lehnt Verbindungen zu Servern ab, deren Zertifikat in dieser Liste enthalten ist.
• PATRONI_SUPERUSER_SSLNEGOTIATION: (optional) entspricht dem Verbindungsparameter sslnegotiation , der steuert, wie die SSL-Verschlüsselung mit dem Server ausgehandelt wird, falls SSL verwendet wird.
• PATRONI_SUPERUSER_GSSENCMODE: (optional) entspricht dem Verbindungsparameter gssencmode , der bestimmt, ob und mit welcher Priorität eine sichere GSS-Verbindung über TCP/IP mit dem Server ausgehandelt wird.
• PATRONI_SUPERUSER_CHANNEL_BINDING: (optional) entspricht dem Verbindungsparameter channel_binding , der die Verwendung von Channel Binding durch den Client steuert.
• PATRONI_REWIND_USERNAME: (optional) Name des Benutzers für pg_rewind; er wird bei der Initialisierung von Postgres 11+ erstellt und erhält alle erforderlichen Berechtigungen .
• PATRONI_REWIND_PASSWORD: (optional) Passwort des Benutzers für pg_rewind; er wird bei der Initialisierung erstellt.
• PATRONI_REWIND_SSLMODE: (optional) entspricht dem Verbindungsparameter sslmode , der dem Client die Auswahl des Modus für die TLS-Aushandlung mit dem Server erlaubt. Einzelheiten zur Funktionsweise der einzelnen Modi stehen in der PostgreSQL-Dokumentation . Der Standardmodus ist prefer.
• PATRONI_REWIND_SSLKEY: (optional) entspricht dem Verbindungsparameter sslkey , der den Speicherort des geheimen Schlüssels für das Clientzertifikat angibt.
• PATRONI_REWIND_SSLPASSWORD: (optional) entspricht dem Verbindungsparameter sslpassword , der das Passwort für den in PATRONI_REWIND_SSLKEY angegebenen geheimen Schlüssel festlegt.
• PATRONI_REWIND_SSLCERT: (optional) entspricht dem Verbindungsparameter sslcert , der den Speicherort des Clientzertifikats angibt.
• PATRONI_REWIND_SSLROOTCERT: (optional) entspricht dem Verbindungsparameter sslrootcert , der den Pfad zu einer Datei mit einem oder mehreren Zertifikaten von Zertifizierungsstellen (CA) angibt, mit denen der Client ein Serverzertifikat prüft.
• PATRONI_REWIND_SSLCRL: (optional) entspricht dem Verbindungsparameter sslcrl , der den Pfad zu einer Datei mit einer Zertifikatsperrliste angibt. Ein Client lehnt Verbindungen zu Servern ab, deren Zertifikat in dieser Liste enthalten ist.
• PATRONI_REWIND_SSLCRLDIR: (optional) entspricht dem Verbindungsparameter sslcrldir , der den Pfad zu einem Verzeichnis mit Dateien angibt, die eine Zertifikatsperrliste enthalten. Ein Client lehnt Verbindungen zu Servern ab, deren Zertifikat in dieser Liste enthalten ist.
• PATRONI_REWIND_SSLNEGOTIATION: (optional) entspricht dem Verbindungsparameter sslnegotiation , der steuert, wie die SSL-Verschlüsselung mit dem Server ausgehandelt wird, falls SSL verwendet wird.
• PATRONI_REWIND_GSSENCMODE: (optional) entspricht dem Verbindungsparameter gssencmode , der bestimmt, ob und mit welcher Priorität eine sichere GSS-Verbindung über TCP/IP mit dem Server ausgehandelt wird.
• PATRONI_REWIND_CHANNEL_BINDING: (optional) entspricht dem Verbindungsparameter channel_binding , der die Verwendung von Channel Binding durch den Client steuert.

REST API

• PATRONI_RESTAPI_THREAD_POOL_SIZE: Größe des Threadpools, mit dem Patroni REST-API-Anfragen verarbeitet. Mindestwert: 5, Standardwert: 5.
• PATRONI_RESTAPI_CONNECT_ADDRESS: IP-Adresse und Port für den Zugriff auf die REST API.
• PATRONI_RESTAPI_LISTEN: IP-Adresse und Port, an denen Patroni auf Verbindungen wartet, um Health-Check-Informationen für HAProxy bereitzustellen.
• PATRONI_RESTAPI_USERNAME: Benutzername für die Basic-Authentifizierung zum Schutz unsicherer REST-API-Endpunkte.
• PATRONI_RESTAPI_PASSWORD: Passwort für die Basic-Authentifizierung zum Schutz unsicherer REST-API-Endpunkte.
• PATRONI_RESTAPI_CERTFILE: gibt die Datei mit dem Zertifikat im PEM-Format an. Ist certfile nicht angegeben oder leer, arbeitet der API-Server ohne SSL.
• PATRONI_RESTAPI_KEYFILE: gibt die Datei mit dem geheimen Schlüssel im PEM-Format an.
• PATRONI_RESTAPI_KEYFILE_PASSWORD: gibt ein Passwort zum Entschlüsseln der Schlüsseldatei an.
• PATRONI_RESTAPI_CAFILE: gibt die Datei mit dem CA_BUNDLE vertrauenswürdiger CA-Zertifikate an, die zum Prüfen der Clientzertifikate verwendet werden.
• PATRONI_RESTAPI_CIPHERS: (optional) gibt die zulässigen Cipher Suites an (z. B. “ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:!SSLv1:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1”)
• PATRONI_RESTAPI_VERIFY_CLIENT: none (Standard), optional oder required. Bei none prüft die REST API keine Clientzertifikate. Bei required sind Clientzertifikate für alle REST-API-Aufrufe erforderlich. Bei optional sind sie für alle unsicheren REST-API-Endpunkte erforderlich. Bei required ist die Clientauthentifizierung erfolgreich, wenn die Prüfung der Zertifikatssignatur erfolgreich ist. Bei optional wird das Clientzertifikat nur bei Anfragen mit PUT, POST, PATCH und DELETE geprüft.
• PATRONI_RESTAPI_ALLOWLIST: (optional): legt die Hosts fest, die unsichere REST-API-Endpunkte aufrufen dürfen. Ein Eintrag kann ein Hostname, eine IP-Adresse oder eine Netzwerkadresse in CIDR-Schreibweise sein. Standardmäßig gilt allow all. Ist allowlist oder allowlist_include_members gesetzt, werden alle nicht enthaltenen Zugriffe abgelehnt.
• PATRONI_RESTAPI_ALLOWLIST_INCLUDE_MEMBERS: (optional): bei true dürfen andere im DCS registrierte Clustermitglieder auf unsichere REST-API-Endpunkte zugreifen (IP-Adresse oder Hostname werden aus api_url des Mitglieds übernommen). Vorsicht: Das Betriebssystem kann für ausgehende Verbindungen eine andere IP-Adresse verwenden.
• PATRONI_RESTAPI_HTTP_EXTRA_HEADERS: (optional) HTTP-Header ermöglichen es dem REST-API-Server, zusätzliche Informationen mit einer HTTP-Antwort zu übertragen.
• PATRONI_RESTAPI_HTTPS_EXTRA_HEADERS: (optional) HTTPS-Header ermöglichen es dem REST-API-Server, bei aktiviertem TLS zusätzliche Informationen mit einer HTTP-Antwort zu übertragen. Die in http_extra_headers festgelegten Zusatzinformationen werden ebenfalls übertragen.
• PATRONI_RESTAPI_REQUEST_QUEUE_SIZE: (optional): legt die Größe der Anfragewarteschlange für den TCP-Socket der Patroni REST API fest. Ist die Warteschlange voll, erhalten weitere Anfragen den Fehler “Connection denied”. Der Standardwert ist 5.
• PATRONI_RESTAPI_SERVER_TOKENS: (optional) konfiguriert den Wert des HTTP-Headers Server. Original (Standard) behält das ursprüngliche Verhalten bei und zeigt die Versionen von BaseHTTP und Python an, etwa BaseHTTP/0.6 Python/3.12.3. Minimal: Der Header enthält nur die Patroni-Version, etwa Patroni/4.0.0. ProductOnly: Der Header enthält nur den Produktnamen, etwa Patroni.

CTL

• PATRONICTL_CONFIG_FILE: (optional) Pfad zur Konfigurationsdatei.
• PATRONI_CTL_USERNAME: (optional) Benutzername für die Basic-Authentifizierung beim Zugriff auf geschützte REST-API-Endpunkte. Ohne Angabe verwendet patronictl den Wert des REST-API-Parameters “username”.
• PATRONI_CTL_PASSWORD: (optional) Passwort für die Basic-Authentifizierung beim Zugriff auf geschützte REST-API-Endpunkte. Ohne Angabe verwendet patronictl den Wert des REST-API-Parameters “password”.
• PATRONI_CTL_INSECURE: (optional) erlaubt Verbindungen zur REST API ohne Prüfung der SSL-Zertifikate.
• PATRONI_CTL_CACERT: (optional) gibt die CA_BUNDLE-Datei oder das Verzeichnis mit Zertifikaten vertrauenswürdiger CAs an, die zum Prüfen der SSL-Zertifikate der REST API verwendet werden. Ohne Angabe verwendet patronictl den Wert des REST-API-Parameters “cafile”.
• PATRONI_CTL_CERTFILE: (optional) gibt die Datei mit dem Clientzertifikat im PEM-Format an.
• PATRONI_CTL_KEYFILE: (optional) gibt die Datei mit dem geheimen Clientschlüssel im PEM-Format an.
• PATRONI_CTL_KEYFILE_PASSWORD: (optional) gibt ein Passwort zum Entschlüsseln der Clientschlüsseldatei an.