Vue imprimable multi-pages de cette section. .

Configuration Patroni

Modèle de configuration Patroni, règles de priorité et outils de validation.

1: Paramètres de configuration dynamique
2: Paramètres de configuration YAML
3: Paramètres de configuration de l'environnement

Il existe 3 types de configuration Patroni :

Configuration dynamique globale pending_restart . Ces options sont stockées dans le magasin de configuration distribué (DCS) et appliquées sur tous les nœuds du cluster. La configuration dynamique peut être définie à tout moment à l’aide de l’outil patronictl_edit_config ou de l’API REST de Patroni REST API . Si les options modifiées ne font pas partie de la configuration au démarrage, elles sont appliquées de manière asynchrone (lors du prochain cycle de réveil) sur chaque nœud, qui est ensuite rechargé. Si le nœud nécessite un redémarrage pour appliquer la configuration (pour les paramètres PostgreSQL avec contexte postmaster, lorsque leurs valeurs ont changé), un indicateur spécial pending_restart indiquant cela est défini dans le fichier JSON members.data. En outre, l’état du nœud indique cela en affichant "restart_pending": true.
Fichier de configuration local patroni.yml (patroni.yml). Ces options sont définies dans le fichier de configuration et ont priorité sur la configuration dynamique. patroni.yml peut être modifié et rechargé en cours d’exécution (sans redémarrage de Patroni) en envoyant le signal SIGHUP au processus Patroni, en effectuant une requête POST /reloadREST-API ou en exécutant patronictl_reload . La configuration locale peut être un fichier YAML unique ou un répertoire. Lorsqu’il s’agit d’un répertoire, tous les fichiers YAML qu’il contient sont chargés un par un dans l’ordre trié. En cas de définition d’une clé dans plusieurs fichiers, l’occurrence dans le dernier fichier a priorité.
Configuration de l’environnement . Il est possible de définir/écraser certains paramètres de configuration « Local » à l’aide de variables d’environnement. La configuration par environnement est particulièrement utile lorsque vous exécutez l’application dans un environnement dynamique et que vous ne connaissez pas certains paramètres à l’avance (par exemple, il n’est pas possible de connaître votre adresse IP externe lorsque vous êtes exécuté à l’intérieur de docker).

Règles importantes

Paramètres PostgreSQL contrôlés par Patroni

Certains paramètres PostgreSQL doivent avoir les mêmes valeurs sur le primaire et les répliques. Pour ces paramètres, les valeurs définies dans les fichiers de configuration localisés de Patroni ou via les variables d’environnement n’ont aucun effet. Pour modifier ou définir leurs valeurs, il faut modifier la configuration partagée dans le DCS. Voici la liste réelle de ces paramètres, accompagnée de leurs valeurs par défaut et minimales :

max_connections : valeur par défaut 100, valeur minimale 25
max_locks_per_transaction : valeur par défaut 64, valeur minimale 32
max_worker_processes : valeur par défaut 8, valeur minimale 2
max_prepared_transactions : valeur par défaut 0, valeur minimale 0
wal_level : valeur par défaut hot_standby, valeurs acceptées : hot_standby, replica, logical
track_commit_timestamp : valeur par défaut off

Pour les paramètres ci-dessous, PostgreSQL n’exige pas que les valeurs soient identiques entre le primaire et toutes les répliques. Toutefois, étant donné la possibilité qu’une réplique devienne le primaire à tout moment, il n’a guère de sens de les configurer différemment ; par conséquent, Patroni limite leur définition à la configuration dynamique .

max_wal_senders : valeur par défaut 10, valeur minimale 3
max_replication_slots : valeur par défaut 10, valeur minimale 4
wal_keep_segments : valeur par défaut 8, valeur minimale 1
wal_keep_size : valeur par défaut 128 Mo, valeur minimale 16 Mo
wal_log_hints : activé

Ces paramètres sont vérifiés afin de s’assurer qu’ils sont valides ou qu’ils atteignent une valeur minimale.

Certains autres paramètres Postgres sont contrôlés par Patroni :

listen_addresses - est défini soit à partir de la variable d’environnement postgresql.listen, soit à partir de la variable d’environnement PATRONI_POSTGRESQL_LISTEN
port - est défini soit à partir de la variable d’environnement postgresql.listen, soit à partir de la variable d’environnement PATRONI_POSTGRESQL_LISTEN
cluster_name - est défini soit à partir de la variable d’environnement scope, soit à partir de la variable d’environnement PATRONI_SCOPE
hot_standby: on

Pour plus de sécurité, les paramètres provenant des listes ci-dessus sont écrits dans postgresql.conf, puis passés sous forme de liste d’arguments à postgres, qui leur accorde la plus haute priorité (sauf wal_keep_segments et wal_keep_size), même au-dessus de ALTER SYSTEM

Il existe également des paramètres tels que PostgreSQL.listen, PostgreSQL.data_dir qui peuvent être définis uniquement localement, c’est-à-dire dans le fichier de configuration Patroni config ou via la variable d’environnement configuration . Dans la plupart des cas, la configuration locale remplace la configuration dynamique.

Lors de l’application des options de configuration locales ou dynamiques, les actions suivantes sont effectuées :

Le nœud vérifie d’abord s’il existe un fichier postgresql.base.conf ou si le paramètre custom_conf est défini.
Si le paramètre custom_conf est défini, le fichier qu’il spécifie est utilisé comme configuration de base, en ignorant postgresql.base.conf et postgresql.conf.
Si le paramètre custom_conf n’est pas défini et que postgresql.base.conf existe, il contient la configuration « originale » renommée et est utilisé comme configuration de base.
Si aucun fichier custom_conf ni postgresql.base.conf n’existe, le fichier postgresql.conf d’origine est renommé en postgresql.base.conf et utilisé comme configuration de base.
Les options dynamiques (à l’exception de celles mentionnées ci-dessus) sont exportées dans postgresql.conf, et une directive d’inclusion est ajoutée dans postgresql.conf vers la configuration de base (soit postgresql.base.conf, soit le fichier situé à custom_conf). Ainsi, il est possible d’appliquer de nouvelles options sans devoir relire le fichier de configuration pour vérifier la présence de l’inclusion.
Certains paramètres essentiels à la gestion du cluster par Patroni sont remplacés par la ligne de commande.
Si une option nécessitant un redémarrage est modifiée (il faut examiner le contexte dans pg_settings et les valeurs réelles de ces options), un indicateur pending_restart est défini sur ce nœud. Cet indicateur est réinitialisé à chaque redémarrage.

Les paramètres seront appliqués dans l’ordre suivant (les paramètres en temps d’exécution ont la priorité la plus élevée) :

charger les paramètres à partir du fichier postgresql.base.conf (ou à partir d’un fichier custom_conf, le cas échéant)
charger les paramètres à partir du fichier postgresql.conf
charger les paramètres à partir du fichier postgresql.auto.conf
paramètre en temps d’exécution utilisant -o --name=value

Cela permet la configuration de tous les nœuds (2), la configuration d’un nœud spécifique à l’aide de ALTER SYSTEM (3) et garantit que les paramètres essentiels au fonctionnement de Patroni sont appliqués (4), tout en laissant de la place aux outils de configuration qui gèrent postgresql.conf directement sans impliquer Patroni (1).

Paramètres PostgreSQL affectant la mémoire partagée

PostgreSQL dispose de certains paramètres qui déterminent la taille de la mémoire partagée qu’ils utilisent :

max_connections
max_prepared_transactions
max_locks_per_transaction
max_wal_senders
max_worker_processes

La modification de ces paramètres nécessite un redémarrage de PostgreSQL pour prendre effet, et leurs structures de mémoire partagée ne peuvent pas être plus petites sur les nœuds secondaires que sur le nœud primaire.

Comme expliqué précédemment, Patroni limite la modification de leurs valeurs à la configuration dynamique , qui comprend généralement :

Application des modifications via patronictl_edit_config (ou via l’API REST /config point d’accès)
Redémarrage des nœuds via patronictl_restart (ou via l’API REST /restart point d’accès)

Note : veillez à redémarrer les nœuds PostgreSQL à l’aide de la commande patronictl_restart , ou via l’endpoint REST /restart. Une tentative de redémarrage de PostgreSQL en redémarrant le démon Patroni, par exemple en exécutant systemctl restart patroni, peut provoquer un basculement dans le cluster, si vous redémarrez le nœud primaire.

Toutefois, comme ces paramètres gèrent la mémoire partagée, une attention particulière doit être portée lors du redémarrage des nœuds :

Si vous souhaitez augmenter la valeur de l’un de ces paramètres :
1. Redémarrez tous les serveurs secondaires en premier
2. Redémarrez le serveur primaire ensuite
Si vous souhaitez réduire la valeur de l’un de ces paramètres :
1. Redémarrez le serveur primaire en premier
2. Redémarrez ensuite tous les serveurs secondaires

Remarque : si vous tentez de redémarrer tous les nœuds en même temps après avoir diminué la valeur de l’un de ces paramètres, Patroni ignorera le changement et redémarrera le secondaire avec la valeur d’origine, ce qui nécessitera de redémarrer à nouveau les secondaires ultérieurement. Patroni agit ainsi pour empêcher le secondaire de tomber dans une boucle de redémarrages infinie, car PostgreSQL quitte avec un message FATAL si vous tentez de définir l’un de ces paramètres à une valeur inférieure à celle visible dans pg_controldata sur le nœud secondaire. Autrement dit, nous ne pouvons diminuer le paramètre sur le secondaire qu’une fois que son pg_controldata est à jour avec le primaire concernant ces modifications apportées au primaire.

Plus d’informations à ce sujet sont disponibles dans Aperçu administrateur PostgreSQL .

Paramètres de configuration Patroni

En outre, les options de configuration suivantes de Patroni peuvent être modifiées uniquement de manière dynamique :

ttl : 30
loop_wait : 10
retry_timeout : 10
maximum_lag_on_failover : 1048576
max_timelines_history : 0
check_timeline : false
PostgreSQL.use_slots : true

Lorsque ces options sont modifiées, Patroni lit la section correspondante de la configuration stockée dans le DCS et met à jour ses valeurs en cours d’exécution.

Les nœuds Patroni enregistrent l’état des options du DCS sur le disque à chaque modification de configuration, dans le fichier patroni.dynamic.json situé dans le répertoire de données de Postgres. Seul le leader est autorisé à restaurer ces options à partir de la sauvegarde sur disque si elles sont totalement absentes du DCS ou si elles sont invalides.

Génération et validation de la configuration

Patroni fournit des interfaces en ligne de commande pour générer et valider une configuration locale . Avec l’exécutable patroni, vous pouvez :

Créez une configuration Patroni d’exemple locale ;
Créez un fichier de configuration Patroni pour l’instance PostgreSQL en cours d’exécution localement (par exemple, comme étape de préparation pour l’intégration Patroni ) ;
Validez un fichier de configuration Patroni donné.

Configuration exemple de Patroni

patroni --generate-sample-config [configfile]

Description

Générez un fichier de configuration Patroni d’exemple au format yaml. Les valeurs des paramètres sont définies à l’aide de la configuration Environnement , sinon, si non définies, les valeurs par défaut utilisées par Patroni ou la chaîne #FIXME sont utilisées pour les valeurs qui devront être définies ultérieurement par l’utilisateur.

Certains valeurs par défaut sont définies en fonction de la configuration locale :

PostgreSQL.listen : l’adresse IP renvoyée par l’appel à gethostname pour le nom d’hôte de la machine actuelle et le port standard 5432.
PostgreSQL.connect_address : l’adresse IP renvoyée par l’appel à gethostname pour le nom d’hôte de la machine actuelle et le port standard 5432.
PostgreSQL.authentication.rewind : n’est défini que si la version de PostgreSQL peut être déterminée à partir du binaire et que la version est 11 ou ultérieure.
restapi.listen : adresse IP renvoyée par l’appel à gethostname pour le nom d’hôte de la machine actuelle et le port standard 8008.
restapi.connect_address : adresse IP renvoyée par l’appel à gethostname pour le nom d’hôte de la machine actuelle et le port standard 8008.

Paramètres

configfile - chemin complet du fichier de configuration utilisé pour stocker le résultat. Si non fourni, le résultat est envoyé à stdout.

Configuration Patroni pour une instance en cours d’exécution

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

Description

Générez une configuration Patroni au format yaml pour l’instance PostgreSQL exécutée localement. Le DSN fourni, qui est prioritaire, ou les variables d’environnement de PostgreSQL serviront à la connexion. Si aucun mot de passe n’est fourni, vous devrez le saisir à l’invite.

Toutes les options GUC non internes définies dans l’instance Postgres source, qu’elles aient été configurées via un fichier de configuration, via la ligne de commande du postmaster ou via des variables d’environnement, serviront de source pour les paramètres de configuration Patroni suivants :

scope : valeur GUC cluster_name ;
PostgreSQL.listen : valeurs GUC listen_addresses et port ;
PostgreSQL.datadir : valeur GUC data_directory ;
PostgreSQL.parameters : valeurs GUC archive_command, restore_command, archive_cleanup_command, recovery_end_command, ssl_passphrase_command, hba_file, ident_file, config_file ;
bootstrap.dcs : toutes les autres valeurs GUC PostgreSQL collectées.

Si scope, postgresql.listen ou postgresql.datadir n’est pas défini à partir des paramètres GUC de Postgres, la valeur respective de la configuration Environment est utilisée.

Autres règles applicables à la définition des valeurs :

name : valeur de la variable d’environnement PATRONI_NAME si définie, sinon le nom d’hôte de la machine actuelle.
PostgreSQL.bin_dir : chemin vers les binaires Postgres extraits de l’instance en cours d’exécution.
PostgreSQL.connect_address : adresse IP renvoyée par l’appel à gethostname pour le nom d’hôte de la machine actuelle et le port utilisé pour la connexion à l’instance, ou la valeur du paramètre GUC port.
PostgreSQL.authentication.superuser : configuration utilisée pour la connexion à l’instance ;
PostgreSQL.pg_hba : lignes extraites depuis le fichier hba_file de l’instance source.
PostgreSQL.pg_ident : lignes extraites depuis le fichier ident_file de l’instance source.
restapi.listen : adresse IP renvoyée par l’appel à gethostname pour le nom d’hôte de la machine actuelle et le port standard 8008.
restapi.connect_address : adresse IP renvoyée par l’appel à gethostname pour le nom d’hôte de la machine actuelle et le port standard 8008.

Les autres paramètres définis à l’aide de la configuration Environnement sont également inclus dans la configuration.

Paramètres

configfile Chemin complet du fichier de configuration utilisé pour stocker le résultat. Si ce chemin n’est pas fourni, le résultat est envoyé à stdout.

dsn Chaîne DSN facultative pour l’instance PostgreSQL locale afin d’obtenir les valeurs GUC.

Valider la configuration Patroni

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

Description

Validez la configuration Patroni fournie et affichez les informations relatives aux vérifications échouées.

Paramètres

configfile Chemin complet du fichier de configuration à vérifier. Si non fourni ou si le fichier n’existe pas, tentera de lire à partir de la variable d’environnement PATRONI_CONFIG_VARIABLE, ou, si elle n’est pas définie, à partir des variables d’environnement Patroni Patroni .

--ignore-listen-port | -i Indicateur facultatif pour ignorer les échecs de liaison des ports listen déjà en cours d’utilisation lors de la validation de configfile.

--print | -p Indicateur facultatif pour afficher la configuration locale (y compris les substitutions de configuration d’environnement) après sa validation réussie.

1 - Paramètres de configuration dynamique

Paramètres de configuration dynamique stockés dans le DCS et appliqués au cluster entier.

La configuration dynamique est stockée dans le magasin de configuration distribué (DCS) et appliquée sur tous les nœuds du cluster.

Pour modifier la configuration dynamique, vous pouvez utiliser soit l’outil patronictl_edit_config , soit l’API REST de Patroni REST API .

loop_wait : nombre de secondes pendant lesquelles la boucle s’endort. Valeur par défaut : 10, valeur minimale possible : 1
ttl : durée de vie du verrou de leader (en secondes). Pensez-y comme la durée avant le déclenchement du processus de basculement automatique. Valeur par défaut : 30, valeur minimale possible : 20
retry_timeout : délai d’attente pour les nouvelles tentatives des opérations DCS et PostgreSQL (en secondes). Les problèmes DCS ou réseau de durée inférieure à cette valeur ne provoqueront pas la désactivation du leader par Patroni. Valeur par défaut : 10, valeur minimale possible : 3

[!AVERTISSEMENT]
Lorsque vous modifiez les valeurs de loop_wait, retry_timeout ou ttl, vous devez respecter la règle suivante :
loop_wait + 2 * retry_timeout <= ttl

maximum_lag_on_failover : le nombre maximum d’octets dont un suiveur peut être en retard pour pouvoir participer à l’élection du leader.
primary_race_backoff : reporte l’élection du leader sur les répliques secondaires de primary_race_backoff secondes si la réplication WAL depuis le primaire progresse encore. Cela permet de réduire les basculements inutiles causés par une réponse temporairement bloquée de Patroni. Valeur par défaut : 0 (désactivé).
maximum_lag_on_syncnode : le nombre maximum d’octets dont un suiveur synchrone peut être en retard avant d’être considéré comme un candidat défaillant et remplacé par un suiveur asynchrone sain. Patroni utilise le LSN du réplique maximum s’il y a plusieurs suiveurs, sinon il utilise le LSN actuel du leader. Valeur par défaut : -1. Patroni ne prendra aucune mesure pour remplacer un suiveur synchrone défaillant lorsque cette valeur est réglée à 0 ou inférieure. Veuillez définir une valeur suffisamment élevée pour éviter que Patroni ne remplace fréquemment un suiveur synchrone pendant des pics de charge transactionnelle.
max_timelines_history : nombre maximum d’éléments d’historique de timeline conservés dans le DCS. Valeur par défaut : 0. Lorsqu’elle est réglée sur 0, l’historique complet est conservé dans le DCS.
primary_start_timeout : durée autorisée à un serveur primaire pour se rétablir après une panne avant que le basculement ne soit déclenché (en secondes). Valeur par défaut : 300 secondes. Si cette valeur est réglée sur 0, le basculement est effectué immédiatement après détection d’une panne, si possible. En cas de réplication asynchrone, un basculement peut entraîner la perte de transactions. Le temps de basculement maximal en cas de panne du primaire est : loop_wait + primary_start_timeout + loop_wait, sauf si primary_start_timeout est égal à zéro, auquel cas il est simplement égal à loop_wait. Ajustez cette valeur en fonction de votre compromis entre durabilité et disponibilité.
primary_stop_timeout : nombre de secondes pendant lesquelles Patroni est autorisé à attendre lors de l’arrêt de Postgres, et qui n’est effectif que lorsque synchronous_mode est activé. Si la valeur est supérieure à 0 et que synchronous_mode est activé, Patroni envoie un signal SIGKILL au postmaster si l’opération d’arrêt dure plus longtemps que la valeur définie par primary_stop_timeout. Définissez cette valeur en fonction de votre compromis entre durabilité et disponibilité. Si ce paramètre n’est pas défini ou est défini à une valeur inférieure ou égale à 0, primary_stop_timeout n’est pas pris en compte.
synchronous_mode : active le mode de réplication synchrone. Valeurs possibles : off, on, quorum. Dans ce mode, le leader gère la gestion de synchronous_standby_names, et seul le dernier leader connu, ou l’une des répliques synchrones, est autorisée à participer à la course au leader. Le mode synchrone garantit que les transactions validées ne seront pas perdues lors d’un basculement, au prix de la perte de disponibilité pour les écritures lorsque Patroni ne peut pas garantir la durabilité des transactions. Voir la documentation sur les modes de réplication pour plus de détails.
synchronous_mode_strict : empêche la désactivation de la réplication synchrone si aucune réplique synchrone n’est disponible, bloquant toutes les écritures clients sur le primaire. Lorsque cette option est définie et qu’aucune réplique admissible n’est en cours de diffusion, Patroni maintient synchronous_standby_names pointant vers les derniers nœuds synchrones connus à partir de la clé /sync du DCS, ou utilise le placeholder interne __patroni_strict_sync_replica_placeholder__ lorsque aucun état synchrone antérieur n’existe. Le nœud name dans patroni.yaml ne doit pas être défini sur __patroni_strict_sync_replica_placeholder__. Consultez la documentation des modes de réplication pour plus de détails.
synchronous_node_count : si le mode synchronous_mode est activé, ce paramètre est utilisé par Patroni pour gérer le nombre précis d’instances de standby synchrones et ajuste l’état dans le DCS ainsi que le paramètre synchronous_standby_names dans PostgreSQL au fur et à mesure que les membres rejoignent ou quittent le cluster. Si la valeur est définie à un nombre supérieur au nombre de nœuds éligibles, elle sera automatiquement ajustée. Valeur par défaut : 1.
failsafe_mode : active le mode DCS Failsafe Mode . Valeur par défaut : false.
PostgreSQL :
- use_pg_rewind : indique si pg_rewind doit être utilisé. Valeur par défaut : false. Notez que le cluster doit avoir été initialisé avec data page checksums (--data-checksums option pour initdb) et/ou wal_log_hints doit être défini à on, sinon pg_rewind ne fonctionnera pas.
- use_slots : indique si les slots de réplication doivent être utilisés. Valeur par défaut : true sur PostgreSQL 9.4+.
- recovery_conf : paramètres de configuration supplémentaires écrits dans recovery.conf lors de la configuration du suiveur. Il n’existe plus de recovery.conf dans PostgreSQL 12, mais vous pouvez continuer à utiliser cette section, car Patroni la gère de manière transparente.
- parameters : paramètres de configuration (GUC) pour Postgres au format {max_connections: 100, wal_level: "replica", max_wal_senders: 10, wal_log_hints: "on"}. La plupart de ces paramètres sont requis pour que la réplication fonctionne.
- parameters_primary : (facultatif) substitutions de paramètres spécifiques au rôle pour le leader. Ces valeurs sont fusionnées avec et remplacent celles du paramètre parameters.
- parameters_replica : (facultatif) substitutions de paramètres spécifiques au rôle pour la réplique. Ces valeurs sont fusionnées avec et remplacent celles du paramètre parameters.
- parameters_standby_leader : (facultatif) substitutions de paramètres spécifiques au rôle pour le standby_leader. Ces valeurs sont fusionnées avec et remplacent celles du paramètre parameters.
- pg_hba : liste de lignes que Patroni utilisera pour générer pg_hba.conf. Patroni ignore ce paramètre si le paramètre PostgreSQL hba_file est défini avec une valeur différente de celle par défaut.
  - - host all all 0.0.0.0/0 md5
  - - host replication replicator 127.0.0.1/32 md5 : une ligne de ce type est obligatoire pour la réplication.
- pg_hba_primary : (facultatif) entrées pg_hba spécifiques au rôle primaire. Elles remplacent entièrement pg_hba (pas de fusion). Si non définies, pg_hba est utilisée.
- pg_hba_replica : (facultatif) entrées pg_hba spécifiques au rôle réplique. Elles remplacent entièrement pg_hba (pas de fusion). Si non définies, pg_hba est utilisée.
- pg_hba_standby_leader : (facultatif) entrées pg_hba spécifiques au rôle standby_leader. Elles remplacent entièrement pg_hba (pas de fusion). Si non définies, pg_hba est utilisée.
- pg_ident : liste de lignes que Patroni utilisera pour générer pg_ident.conf. Patroni ignore ce paramètre si le paramètre ident_file PostgreSQL est défini avec une valeur autre que celle par défaut.
  - - mapname1 systemname1 pguser1
  - - mapname1 systemname2 pguser2
- pg_ident_primary : (facultatif) entrées pg_ident spécifiques au rôle primaire. Elles remplacent entièrement pg_ident (pas de fusion). Si non définies, pg_ident est utilisée.
- pg_ident_replica : (facultatif) entrées pg_ident spécifiques au rôle réplique. Elles remplacent entièrement pg_ident (pas de fusion). Si non définies, pg_ident est utilisée.
- pg_ident_standby_leader : (facultatif) entrées pg_ident spécifiques au rôle cluster de secours leader. Elles remplacent entièrement pg_ident (pas de fusion). Si non définies, pg_ident est utilisée.
standby_cluster : si cette section est définie, un amorçage d’un cluster de secours est requis.
- host : adresse du nœud distant
- port : port du nœud distant
- primary_slot_name : nom de la slot à utiliser sur le nœud distant pour la réplication. Ce paramètre est facultatif ; sa valeur par défaut est dérivée du nom de l’instance (voir la fonction slot_name_from_member_name).
- create_replica_methods : liste ordonnée des méthodes pouvant être utilisées pour amorcer un leader de secours à partir du primaire distant, peut différer de la liste définie dans postgresql_settings
- restore_command : commande permettant de restaurer les enregistrements WAL depuis le primaire distant vers les nœuds d’un cluster de secours, peut différer de la liste définie dans postgresql_settings
- archive_cleanup_command : commande de nettoyage pour le leader de secours
- recovery_min_apply_delay : durée d’attente avant d’appliquer réellement les enregistrements WAL sur un leader de secours
member_slots_ttl : durée de rétention des slots de réplication physique pour les répliques lorsqu’elles sont arrêtées. Valeur par défaut : 30min. Définissez-la sur 0 si vous souhaitez conserver le comportement ancien (lorsque la clé du membre expire dans le DCS, le slot est supprimé immédiatement). Cette fonctionnalité n’est disponible qu’à partir de PostgreSQL 11.
slots : définir des slots de réplication permanents. Ces slots seront préservés lors d’un basculement planifié ou d’un basculement. Les slots permanents qui n’existent pas seront créés par Patroni. À partir de PostgreSQL 11, les slots physiques permanents sont créés sur tous les nœuds et leur position est avancée toutes les loop_wait secondes. Pour les versions de PostgreSQL antérieures à 11, les slots de réplication physiques permanents ne sont maintenus que sur le primaire actuel. Les slots logiques sont copiés depuis le primaire vers une réplique lors d’un redémarrage, puis leur position est avancée toutes les loop_wait secondes (le cas échéant). La copie des fichiers de slots logiques s’effectue via la connexion libpq et à l’aide des identifiants de rewind ou des identifiants de superutilisateur (voir la section PostgreSQL.authentication). Il existe toujours un risque que la position du slot logique sur la réplique soit légèrement en retard par rapport au précédent primaire, l’application doit donc être préparée à recevoir certains messages une seconde fois après un basculement. La méthode la plus simple consiste à suivre confirmed_flush_lsn. L’activation des slots de réplication permanents nécessite que PostgreSQL.use_slots soit défini à true. Si des slots de réplication logiques permanents sont définis, Patroni les activera automatiquement hot_standby_feedback. Étant donné que le basculement des slots de réplication logiques est dangereux sous PostgreSQL 9.6 et versions antérieures, et que PostgreSQL 10 manque certaines fonctions essentielles, cette fonctionnalité n’est disponible qu’avec PostgreSQL 11+.
- my_slot_name : le nom de la slot de réplication permanente. Si le nom de la slot permanente correspond à celui du nœud actuel, celle-ci ne sera pas créée sur ce nœud. Si vous ajoutez une slot de réplication physique permanente dont le nom correspond à celui d’un membre Patroni, Patroni veillera à ce que la slot créée ne soit pas supprimée, même si le membre correspondant devient inactif, situation qui entraînerait normalement la suppression de la slot par Patroni. Bien que cela puisse être utile dans certaines situations, par exemple lorsque vous souhaitez que les slots de réplication utilisés par les membres persistent pendant des défaillances temporaires ou lors de l’importation de membres existants dans un nouveau cluster Patroni (voir Convert a Standalone to a Patroni Cluster pour plus de détails), l’opérateur doit exercer une prudence particulière afin que ces conflits de noms ne soient pas persistés dans le DCS, lorsque la slot n’est plus nécessaire, en raison de leur impact sur le fonctionnement normal de Patroni.
  - type : type de slot. Peut être physical ou logical. Si le slot est logique, vous devez également définir database et plugin. Si le slot est physique, vous pouvez éventuellement définir cluster_type.
  - database : nom de la base de données où les slots logiques doivent être créés.
  - plugin : nom du plugin pour le slot logique.
  - cluster_type : type de cluster (primary ou standby) sur lequel le slot doit être créé, sinon il ne sera pas créé ou un slot existant sera supprimé.
ignore_slots : liste de jeux de propriétés de slot de réplication que Patroni doit ignorer. Cette configuration/ce fonctionnalité est utile lorsque certains slots de réplication sont gérés en dehors de Patroni. Toute sous-ensemble de propriétés correspondantes entraînera l’ignorance d’un slot.
- name : nom du slot de réplication.
- type : type de slot. Peut être physical ou logical. Si le slot est logique, vous pouvez éventuellement définir database et/ou plugin.
- database : le nom de la base de données (lorsqu’il correspond à une borne logical).
- plugin : le plugin de décodage logique (lorsqu’il correspond à une borne logical).

Note : slots est une carte associatives tandis que ignore_slots est un tableau. Par exemple :

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
  ...

Note : Lorsque PostgreSQL v11 ou une version ultérieure est utilisé, Patroni maintient des slots de réplication physique sur tous les nœuds pouvant devenir un leader, afin que les nœuds répliques conservent les segments WAL réservés s’ils sont potentiellement requis par d’autres nœuds. Si un nœud est absent et que sa clé membre dans le DCS expire, le slot de réplication correspondant est supprimé après member_slots_ttl (valeur par défaut : 30min). Vous pouvez ajuster cette durée en fonction de vos besoins. En alternative, si la topologie du cluster est statique (nombre fixe de nœuds dont les noms ne changent jamais), vous pouvez configurer des slots de réplication physique permanents nommés selon les noms des nœuds afin d’éviter la suppression des slots et le recyclage des fichiers WAL pendant une indisponibilité temporaire de la réplique :

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

[!AVERTISSEMENT]
Les slots de réplication permanents ne sont synchronisés qu’à partir du primary/standby_leader vers les nœuds répliques. Cela signifie que les applications doivent les utiliser uniquement depuis le nœud leader. Leur utilisation sur les nœuds répliques entraîne une croissance indéfinie de pg_wal sur tous les autres nœuds du cluster. Une exception à cette règle concerne les slots physiques correspondant aux noms des membres Patroni (créés et gérés par Patroni). Ces slots sont synchronisés entre tous les nœuds, car ils sont utilisés pour la réplication entre eux.

[!AVERTISSEMENT]
Définir l’étiquette nostream sur un nœud de secours désactive la copie et la synchronisation des emplacements de réplication logique permanents sur ce nœud lui-même et sur toutes ses répliques en cascade, le cas échéant.

2 - Paramètres de configuration YAML

Référence complète des options et sections de configuration YAML pour Patroni

Global/Universel

thread_pool_size : taille du pool de threads utilisé par Patroni pour exécuter les tâches asynchrones et communiquer via l’API REST avec les autres membres lors d’une course au leader ou lors de vérifications en mode d’urgence. Valeur minimale : 5, valeur par défaut : 5.
thread_stack_size : spécifie la taille de la pile à utiliser pour les threads lancés par Patroni. La valeur doit être alignée sur 64kB. Valeur minimale : 64kB, valeur par défaut (définie par Patroni) : 512kB.
name : le nom de l’hôte. Doit être unique dans le cluster. La valeur __patroni_strict_sync_replica_placeholder__ est réservée à une utilisation interne par Patroni et ne peut pas être utilisée comme nom de nœud.
namespace : chemin dans le magasin de configuration où Patroni stockera les informations sur le cluster. Valeur par défaut : “/service”
scope : nom du cluster

Journalisation

type : définit le format des journaux. Peut être soit plain soit json. Pour utiliser le format json, vous devez avoir installé jsonlogger . La valeur par défaut est plain.
level : définit le niveau général de journalisation. La valeur par défaut est INFO (voir la documentation sur le module logging de Python )
traceback_level : définit le niveau à partir duquel les traces d’erreur sont visibles. La valeur par défaut est ERROR. Définissez-la sur DEBUG si vous souhaitez voir les traces d’erreur uniquement lorsque log.level=DEBUG est activé.
format : définit la chaîne de formatage des journaux. Si le type de journal est plain, le format de journal doit être une chaîne. Reportez-vous à les attributs LogRecord pour obtenir la liste des attributs disponibles. Si le type de journal est json, le format de journal peut être une liste en plus d’une chaîne. Chaque élément de la liste doit correspondre à un attribut LogRecord. Prenez garde à ce que seul le nom du champ soit requis, et que les %( et ) doivent être omis. Si vous souhaitez afficher un champ de journal avec un nom de clé différent, utilisez un dictionnaire où la clé du dictionnaire est le champ de journal, et la valeur est le nom du champ que vous souhaitez afficher dans le journal. Valeur par défaut : %(asctime)s %(levelname)s : %(message)s
dateformat : définit la chaîne de formatage de la date et de l’heure. (voir la documentation de formatTime() )
static_fields : ajoute des champs supplémentaires au journal. Cette option n’est disponible que lorsque le type de journal est défini sur json.
max_queue_size : Patroni utilise une journalisation en deux étapes. Les enregistrements de journal sont écrits dans une file mémoire et un thread distinct les extrait de la file pour les écrire sur stderr ou dans un fichier. La taille maximale de la file interne est limitée par défaut à 1000 enregistrements, ce qui suffit à conserver les journaux des dernières 1h20.
dir : Répertoire dans lequel écrire les journaux d’application. Le répertoire doit exister et être accessible en écriture par l’utilisateur exécutant Patroni. Si cette valeur est définie, l’application conserve par défaut 4 fichiers de journaux de 25 Mo chacun. Vous pouvez ajuster ces valeurs de rétention à l’aide de file_num et file_size (voir ci-dessous).
mode : Permissions des fichiers de journal (par exemple, 0644). Si non spécifié, les permissions sont déterminées selon la valeur courante de umask.
file_num : Nombre de fichiers de journaux d’application à conserver.
file_size : Taille du fichier patroni.log (en octets) qui déclenche un roulement des journaux.
loggers : Cette section permet de redéfinir le niveau de journalisation par module Python.
- Patroni.postmaster : AVERTISSEMENT
- urllib3 : DEBUG
deduplicate_heartbeat_logs : Si défini à true, les journaux de battement de cœur identiques successifs ne seront pas affichés. La valeur par défaut est false.

[!AVERTISSEMENT]
Le moment auquel la boucle HA s’exécute peut constituer une information très utile pour diagnostiquer les basculements dus à une épuisement des ressources et à des problèmes similaires. Lorsque deduplicate_heartbeat_logs est défini sur true, aucun journal n’est généré pour l’exécution de la boucle HA (sauf en cas de changement de leader), ce qui fait que cette information potentiellement utile ne sera pas disponible dans les journaux.

Voici un exemple de configuration de Patroni pour activer la journalisation au format JSON.

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

Configuration d’amorçage

Note

Une fois que Patroni a initialisé le cluster pour la première fois et que les paramètres ont été stockés dans le DCS, toutes les modifications ultérieures apportées à la section bootstrap.dcs du fichier de configuration YAML n’auront aucun effet ! Pour les modifier, utilisez soit la commande patronictl_edit_config , soit l’API REST de Patroni REST API .

amorçage :
- dcs : Cette section sera écrite dans /<namespace>/<scope>/config du magasin de configuration donné après l’amorçage du nouveau cluster. La configuration dynamique globale du cluster. Vous pouvez y placer n’importe quel paramètre décrit dans les Paramètres de configuration dynamique sous bootstrap.dcs ; une fois Patroni initialisé (amorcé) le nouveau cluster, il écrira cette section dans /<namespace>/<scope>/config du magasin de configuration.
- method : script personnalisé à utiliser pour amorcer ce cluster.
  Consultez la documentation des méthodes d’amorçage personnalisées pour plus de détails. Lorsque initdb est spécifié, la commande par défaut initdb est utilisée. initdb est également déclenché lorsque le paramètre method est absent du fichier de configuration.
- initdb : (facultatif) liste des options à passer à initdb.
  - - data-checksums : doit être activé lorsque pg_rewind est nécessaire sur la version 9.3.
  - - encoding : UTF8 : encodage par défaut pour les nouvelles bases de données.
  - - locale : UTF8 : paramètre régional par défaut pour les nouvelles bases de données.
- post_bootstrap ou post_init : un script supplémentaire exécuté après l’initialisation du cluster. Le script reçoit une chaîne de connexion au format URL (avec l’utilisateur superutilisateur du cluster). La variable PGPASSFILE est définie sur le chemin d’accès au fichier pgpass.

Citus

Active l’intégration de Patroni avec Citus . Si configuré, Patroni s’occupe de l’enregistrement des nœuds workers Citus sur le coordinateur. Vous trouverez plus d’informations sur le support Citus ici .

groupe : l’identifiant du groupe Citus, entier. Utilisez 0 pour le coordinateur et 1, 2, etc. pour les workers
base_de_données : la base de données où l’extension citus doit être créée. Doit être identique sur le coordinateur et tous les workers. Actuellement, une seule base de données est prise en charge.

Consul

La plupart des paramètres sont facultatifs, mais vous devez renseigner host ou url.

host : l’hôte:port de l’agent local Consul.
url : URL de l’agent local Consul, au format : http(s)://host:port.
port : (facultatif) port de Consul.
scheme : (facultatif) http ou https, par défaut http.
token : (facultatif) jeton ACL.
verify : (facultatif) indique si le certificat SSL doit être vérifié pour les requêtes HTTPS.
cacert : (facultatif) certificat CA. Si présent, active la validation.
cert : (facultatif) fichier contenant le certificat client.
key : (facultatif) fichier contenant la clé client. Peut être vide si la clé est incluse dans cert.
dc : (facultatif) Centre de données avec lequel établir la communication. Par défaut, la centrale de l’hôte est utilisée.
consistency : (facultatif) Sélectionne le mode de cohérence de consul. Les valeurs possibles sont default, consistent ou stale (plus de détails dans référence API consul )
checks : (facultatif) liste des vérifications de santé Consul utilisées pour la session. Par défaut, une liste vide est utilisée.
register_service : (facultatif) indique s’il faut enregistrer un service avec le nom défini par le paramètre scope et l’étiquette master, primary, replica ou standby-leader selon le rôle du nœud. La valeur par défaut est false.
service_tags : (facultatif) étiquettes statiques supplémentaires à ajouter au service Consul, en plus du rôle (primary/replica/standby-leader). Par défaut, une liste vide est utilisée.
service_check_interval : (facultatif) fréquence à laquelle effectuer la vérification de santé contre l’URL enregistrée. Valeur par défaut : « 5s ».
service_check_tls_server_name : (facultatif) remplacer le nom d’hôte SNI lors de la connexion via TLS, voir également référence de l’API de vérification du nœud Consul .

Le token doit disposer des autorisations ACL suivantes :

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

etcd

La plupart des paramètres sont facultatifs, mais vous devez spécifier l’un des éléments suivants : host, hosts, url, proxy ou srv

host : l’hôte:port de l’endpoint etcd.
hosts : liste des endpoints etcd au format hôte1:port1,hôte2:port2,etc. Peut être une chaîne séparée par des virgules ou une liste YAML réelle.
use_proxies : si ce paramètre est défini à true, Patroni considère hosts comme une liste de proxys et ne procède pas à la découverte de la topologie du cluster etcd.
url : URL de l’endpoint etcd.
proxy : URL du proxy pour etcd. Si vous vous connectez à etcd via un proxy, utilisez ce paramètre au lieu de url.
srv : Domaine dans lequel rechercher les enregistrements SRV pour la découverte automatique du cluster. Patroni tentera de consulter ces noms de service SRV pour le domaine spécifié (dans cet ordre, jusqu’à la première réussite) : _etcd-client-ssl, _etcd-client, _etcd-ssl, _etcd, _etcd-server-ssl, _etcd-server. Si des enregistrements SRV pour _etcd-server-ssl ou _etcd-server sont récupérés, le protocole pair ETCD sera utilisé pour interroger ETCD afin d’obtenir la liste des membres disponibles. Sinon, les hôtes provenant des enregistrements SRV seront utilisés.
srv_suffix : Configure un suffixe pour le nom SRV interrogé lors de la découverte. Utilisez cette option pour distinguer plusieurs clusters etcd sous le même domaine. Fonctionne uniquement en conjonction avec srv. Par exemple, si srv_suffix: foo et srv: example.org sont définis, la requête DNS SRV suivante est effectuée : _etcd-client-ssl-foo._tcp.example.com (et ainsi de suite pour chaque nom de service SRV etcd possible).
protocol : (facultatif) http ou https, si non spécifié, http est utilisé. Si url ou proxy est spécifié, le protocole est déduit de ces valeurs.
username : (facultatif) nom d’utilisateur pour l’authentification etcd.
password : (facultatif) mot de passe pour l’authentification etcd.
cacert : (facultatif) certificat CA. Si présent, active la validation.
cert : (facultatif) fichier contenant le certificat client.
key : (facultatif) fichier contenant la clé client. Peut être vide si la clé est incluse dans cert.

Etcdv3

Si vous souhaitez que Patroni fonctionne avec un cluster etcd via la version 3 du protocole, vous devez utiliser la section etcd3 dans le fichier de configuration de Patroni. Tous les paramètres de configuration sont identiques à ceux de etcd.

[!AVERTISSEMENT]
Les clés créées avec la version 2 du protocole ne sont pas visibles avec la version 3 du protocole, et inversement ; il n’est donc pas possible de passer de etcd à etcd3 en mettant simplement à jour le fichier de configuration Patroni. En outre, Patroni utilise la passerelle gRPC d’etcd (proxy) pour communiquer avec l’API V3, ce qui rend l’authentification par nom commun TLS impossible.

ZooKeeper

hosts : Liste des membres du cluster ZooKeeper au format : $'host1:port1', 'host2:port2', 'etc...'$ .
use_ssl : (facultatif) Indique si le protocole SSL est utilisé. Valeur par défaut : false. Si défini à false, tous les paramètres spécifiques à SSL sont ignorés.
cacert : (facultatif) Certificat de l’autorité de certification. Présence de ce champ active la validation.
cert : (facultatif) Fichier contenant le certificat client.
key : (facultatif) Fichier contenant la clé client.
key_password : (facultatif) Mot de passe de la clé client.
verify : (facultatif) Indique si la vérification du certificat doit être effectuée ou non. La valeur par défaut est true.
set_acls : (facultatif) Si défini, configure Kazoo pour appliquer une ACL par défaut à chaque ZNode qu’il crée. Les ACL peuvent utiliser le schéma x509 (par défaut) ou d’autres schémas ZooKeeper pris en charge, tels que digest. Elles doivent être spécifiées sous forme de dictionnaire, où la clé est le principal complet (éventuellement préfixé par le schéma) et la valeur une liste de permissions. Les permissions peuvent être une ou plusieurs des valeurs suivantes : CREATE, READ, WRITE, DELETE, ADMIN, ou ALL. Par exemple, set_acls: {CN=principal1: [CREATE, READ], digest:principal2:+pjROuBuuwNNSujKyH8dGcEnFPQ=: [ALL]}.
auth_data : (facultatif) Informations d’authentification à utiliser pour la connexion. Doit être un dictionnaire au format où scheme est la clé et credential la valeur. Valeur par défaut : dictionnaire vide.

Note

Il est obligatoire d’installer kazoo>=2.6.0 pour prendre en charge le SSL.

Exposant

hosts : liste initiale des nœuds Exhibitor (ZooKeeper) au format : « host1,host2,etc… ». Cette liste est mise à jour automatiquement chaque fois que la topologie du cluster Exhibitor (ZooKeeper) change.
poll_interval : fréquence à laquelle la liste des nœuds ZooKeeper et Exhibitor doit être actualisée depuis Exhibitor.
port : port Exhibitor.

Kubernetes

bypass_api_service : (facultatif) Lors de la communication avec l’API Kubernetes, Patroni utilise généralement le service kubernetes , dont l’adresse est exposée dans les pods via la variable d’environnement KUBERNETES_SERVICE_HOST. Si bypass_api_service est défini sur true, Patroni résout la liste des nœuds API derrière le service et établit une connexion directe avec eux.
namespace : (facultatif) espace de noms Kubernetes dans lequel s’exécute le pod Patroni. Valeur par défaut : default.
labels : Étiquettes au format {label1: value1, label2: value2}. Ces étiquettes seront utilisées pour localiser les objets existants (Pods et soit des Endpoints, soit des ConfigMaps) associés au cluster actuel. Patroni les définira également sur chaque objet (Endpoint ou ConfigMap) qu’il crée.
scope_label : (facultatif) nom de l’étiquette contenant le nom du cluster. Valeur par défaut : cluster-name.
bootstrap_labels : (facultatif) Étiquettes au format {label1: value1, label2: value2}. Ces étiquettes seront attribuées au pod Patroni lorsque son état est initializing new cluster, running custom bootstrap script, starting after custom bootstrap ou creating replica.
role_label : (facultatif) nom de l’étiquette contenant le rôle (primary, replica ou autre valeur personnalisée). Patroni définira cette étiquette sur le pod dans lequel il s’exécute. Valeur par défaut : role.
leader_label_value : (facultatif) valeur de l’étiquette du pod lorsque le rôle de Postgres est primary. Valeur par défaut : primary.
follower_label_value : (facultatif) valeur de l’étiquette du pod lorsque le rôle de Postgres est replica. Valeur par défaut : replica.
standby_leader_label_value : (facultatif) valeur de l’étiquette du pod lorsque le rôle de Postgres est standby_leader. Valeur par défaut : primary.
tmp_role_label : (facultatif) nom de l’étiquette temporaire contenant le rôle (primary ou replica). La valeur de cette étiquette utilisera toujours la valeur par défaut correspondante au rôle. À définir uniquement si nécessaire.
use_endpoints : (facultatif) si défini à true, Patroni utilisera des Endpoints au lieu de ConfigMaps pour effectuer les élections du leader et maintenir l’état du cluster.
pod_ip : (facultatif) adresse IP du pod dans lequel s’exécute Patroni. Cette valeur est requise lorsque use_endpoints est activé et est utilisée pour remplir les sous-ensembles du point de terminaison leader lorsque le PostgreSQL du pod est promu.
ports : (facultatif) si l’objet Service possède un nom de port, ce même nom doit apparaître dans l’objet Endpoint, sinon le service ne fonctionnera pas. Par exemple, si votre service est défini comme {Kind: Service, spec: {ports: [{name: postgresql, port: 5432, targetPort: 5432}]}}, vous devez définir kubernetes.ports: [{"name": "postgresql", "port": 5432}] et Patroni l’utilisera pour mettre à jour les sous-ensembles de l’Endpoint leader. Ce paramètre n’est utilisé que si kubernetes.use_endpoints est défini.
cacert : (facultatif) indique le fichier CA_BUNDLE contenant les certificats des autorités de certification approuvées pour vérifier les certificats SSL de l’API Kubernetes. En l’absence de valeur, Patroni utilise celle du secret ServiceAccount.
retriable_http_codes : (facultatif) liste des codes d’état HTTP de l’API K8s pour lesquels une nouvelle tentative doit être effectuée. Par défaut, Patroni réessaie pour 500, 503 et 504, ou lorsque la réponse de l’API K8s contient l’en-tête HTTP retry-after.

Raft (obsolète)

self_addr : adresse ip:port d’écoute des connexions Raft. self_addr doit être accessible depuis les autres nœuds du cluster. Sans cette valeur, le nœud ne participe pas au consensus.
bind_addr : (facultatif) ip:port sur lequel écouter pour les connexions Raft. Si non spécifié, self_addr sera utilisé.
partner_addrs : liste des autres nœuds Patroni du cluster au format :
$'ip1:port', 'ip2:port', 'etc...'$
data_dir : répertoire dans lequel stocker le journal Raft et les instantanés. Si non spécifié, le répertoire de travail actuel est utilisé.
password : (facultatif) Chiffrer le trafic Raft avec un mot de passe spécifié, nécessite le module cryptography.
min_timeout : (facultatif) délai minimum d’élection en secondes pour l’implémentation Raft sous-jacente pysyncobj. Doit être supérieur à 3 × append_entries_period. Valeur par défaut : 0.4.
max_timeout : (facultatif) délai maximum d’élection en secondes pour l’implémentation Raft sous-jacente pysyncobj. Doit être supérieur à min_timeout. Valeur par défaut : 1.4.
connection_timeout : (facultatif) durée en secondes après laquelle une connexion sans réception de données est considérée comme inactive. Doit être supérieur ou égal à max_timeout. Valeur par défaut : 3.5.
append_entries_period : (facultatif) intervalle en secondes pour l’envoi des commandes de battement de cœur (append_entries). Doit être inférieur à un tiers de min_timeout. Valeur par défaut : 0.1.
connection_retry_time : (facultatif) intervalle en secondes entre les tentatives de reconnexion aux nœuds hors ligne. Valeur par défaut : 5.0.
leader_fallback_timeout : (facultatif) durée en secondes après laquelle un leader ne recevant aucune réponse de la majorité redevient un suiveur. Doit être supérieur à append_entries_period. Valeur par défaut : 30.0.

Note

Ces paramètres de temporisation sont utiles dans les réseaux à forte latence où les temporisations par défaut de pysyncobj sont trop strictes. Les contraintes suivantes doivent être respectées : min_timeout > 3 * append_entries_period, max_timeout > min_timeout, connection_timeout >= max_timeout et leader_fallback_timeout > append_entries_period. Patroni vérifie ces conditions au démarrage et refuse de s’exécuter si elles sont violées. Ces valeurs ne peuvent pas être modifiées en cours d’exécution et nécessitent un redémarrage.

[!AVERTISSEMENT] Ces paramètres ne font que relâcher les temporisations d’élection et de connexion de pysyncobj ; ils n’étendent pas le délai maximal par commande que Patroni applique aux opérations Raft. Chaque commande Raft (rafraîchissement du verrou du leader, écriture de l’état du cluster) doit toujours s’achever dans un délai de retry_timeout (valeur par défaut 10). Sur des liens à très forte latence — environ au-dessus de quelques secondes de temps de trajet aller-retour — une seule commande peut dépasser retry_timeout même si connection_timeout est porté bien au-dessus du RTT, ce qui fait que le DCS semble inaccessible et le primaire peut être rétrogradé. Sur de tels liens, il faut également augmenter retry_timeout et ttl en conséquence, tout en maintenant loop_wait + 2 * retry_timeout <= ttl.

FAQ rapide sur l’implémentation Raft

Q : Comment lister tous les nœuds fournissant le consensus ?
A : syncobj_admin -conn host:port -status où l’adresse hôte:port correspond à l’adresse d’un nœud du cluster
Q : Nœud qui faisait partie du consensus et qui a disparu ; je ne peux pas réutiliser la même IP pour un autre nœud. Comment supprimer ce nœud du consensus ?
A : syncobj_admin -conn host:port -remove host2:port2 où host2:port2 correspond à l’adresse du nœud que vous souhaitez supprimer de la consensus.
Q : Où obtenir l’utilitaire syncobj_admin ?
A : Il est installé conjointement avec le module pysyncobj (implémentation Python du protocole RAFT), qui est une dépendance de Patroni.
Q : Est-il possible d’exécuter un nœud Patroni sans l’ajouter au consensus ?
A : Oui, il suffit de commenter ou de supprimer raft.self_addr dans la configuration de Patroni.
Q : Est-il possible d’exécuter Patroni et PostgreSQL uniquement sur deux nœuds ?
A : Oui, sur le troisième nœud, vous pouvez exécuter patroni_raft_controller (sans Patroni ni PostgreSQL). Dans un tel déploiement, il est possible de perdre temporairement un nœud sans affecter le primaire.

PostgreSQL

PostgreSQL :
- authentification :
  - superutilisateur :
    - utilisateur : nom de l’utilisateur superutilisateur, défini lors de l’initialisation (initdb) et utilisé ultérieurement par Patroni pour se connecter à PostgreSQL.
    - mot_de_passe : mot de passe de l’utilisateur superutilisateur, défini lors de l’initialisation (initdb).
    - sslmode : (facultatif) correspond au paramètre de connexion sslmode , qui permet à un client de spécifier le mode de négociation TLS avec le serveur. Pour plus d’informations sur le fonctionnement de chaque mode, veuillez consulter la documentation PostgreSQL . Le mode par défaut est prefer.
    - sslkey : (facultatif) correspond au paramètre de connexion sslkey , qui précise l’emplacement de la clé secrète utilisée avec le certificat client.
    - sslpassword : (facultatif) correspond au paramètre de connexion sslpassword , qui précise le mot de passe de la clé secrète spécifiée dans sslkey.
    - sslcert : (facultatif) correspond au paramètre de connexion sslcert , qui précise l’emplacement du certificat client.
    - sslrootcert : (facultatif) correspond au paramètre de connexion sslrootcert , qui précise l’emplacement d’un fichier contenant un ou plusieurs certificats d’autorités de certification (CA) utilisés par le client pour vérifier le certificat d’un serveur.
    - sslcrl : (facultatif) correspond au paramètre de connexion sslcrl , qui précise l’emplacement d’un fichier contenant une liste de révocation de certificats. Un client refusera la connexion à tout serveur dont le certificat figure dans cette liste.
    - sslcrldir : (facultatif) correspond au paramètre de connexion sslcrldir , qui précise l’emplacement d’un répertoire contenant des fichiers listant les certificats révoqués. Un client refusera de se connecter à tout serveur dont le certificat figure dans cette liste.
    - sslnegotiation : (facultatif) correspond au paramètre de connexion sslnegotiation , qui contrôle la négociation du chiffrement SSL avec le serveur, le cas échéant.
    - gssencmode : (facultatif) correspond au paramètre de connexion gssencmode , qui détermine si une connexion TCP/IP sécurisée GSS sera négociée avec le serveur, et avec quelle priorité
    - channel_binding : (facultatif) correspond au paramètre de connexion channel_binding , qui contrôle l’utilisation du binding de canal par le client.
  - replication :
    - username : nom d’utilisateur de réplication ; l’utilisateur sera créé lors de l’initialisation. Les répliques utiliseront cet utilisateur pour accéder à la source de réplication via la réplication en flux
    - password : mot de passe de réplication ; l’utilisateur sera créé lors de l’initialisation.
    - sslmode : (facultatif) correspond au paramètre de connexion sslmode , qui permet à un client de spécifier le mode de négociation TLS avec le serveur. Pour plus d’informations sur le fonctionnement de chaque mode, veuillez consulter la documentation PostgreSQL . Le mode par défaut est prefer.
    - sslkey : (facultatif) correspond au paramètre de connexion sslkey , qui précise l’emplacement de la clé secrète utilisée avec le certificat client.
    - sslpassword : (facultatif) correspond au paramètre de connexion sslpassword , qui précise le mot de passe de la clé secrète spécifiée dans sslkey.
    - sslcert : (facultatif) correspond au paramètre de connexion sslcert , qui précise l’emplacement du certificat client.
    - sslrootcert : (facultatif) correspond au paramètre de connexion sslrootcert , qui précise l’emplacement d’un fichier contenant un ou plusieurs certificats d’autorités de certification (CA) utilisés par le client pour vérifier le certificat d’un serveur.
    - sslcrl : (facultatif) correspond au paramètre de connexion sslcrl , qui précise l’emplacement d’un fichier contenant une liste de révocation de certificats. Un client refusera la connexion à tout serveur dont le certificat figure dans cette liste.
    - sslcrldir : (facultatif) correspond au paramètre de connexion sslcrldir , qui précise l’emplacement d’un répertoire contenant des fichiers listant les certificats révoqués. Un client refusera de se connecter à tout serveur dont le certificat figure dans cette liste.
    - sslnegotiation : (facultatif) correspond au paramètre de connexion sslnegotiation , qui contrôle la négociation du chiffrement SSL avec le serveur, le cas échéant.
    - gssencmode : (facultatif) correspond au paramètre de connexion gssencmode , qui détermine si une connexion TCP/IP sécurisée GSS sera négociée avec le serveur, et avec quelle priorité
    - channel_binding : (facultatif) correspond au paramètre de connexion channel_binding , qui contrôle l’utilisation du binding de canal par le client.
  - rewind :
    - username : (facultatif) nom de l’utilisateur pour pg_rewind ; l’utilisateur sera créé lors de l’initialisation de PostgreSQL 11+ et toutes les permissions nécessaires lui seront accordées.
    - password : (facultatif) mot de passe de l’utilisateur pour pg_rewind ; l’utilisateur sera créé lors de l’initialisation.
    - sslmode : (facultatif) correspond au paramètre de connexion sslmode , qui permet à un client de spécifier le mode de négociation TLS avec le serveur. Pour plus d’informations sur le fonctionnement de chaque mode, veuillez consulter la documentation PostgreSQL . Le mode par défaut est prefer.
    - sslkey : (facultatif) correspond au paramètre de connexion sslkey , qui précise l’emplacement de la clé secrète utilisée avec le certificat client.
    - sslpassword : (facultatif) correspond au paramètre de connexion sslpassword , qui précise le mot de passe de la clé secrète spécifiée dans sslkey.
    - sslcert : (facultatif) correspond au paramètre de connexion sslcert , qui précise l’emplacement du certificat client.
    - sslrootcert : (facultatif) correspond au paramètre de connexion sslrootcert , qui précise l’emplacement d’un fichier contenant un ou plusieurs certificats d’autorités de certification (CA) utilisés par le client pour vérifier le certificat d’un serveur.
    - sslcrl : (facultatif) correspond au paramètre de connexion sslcrl , qui précise l’emplacement d’un fichier contenant une liste de révocation de certificats. Un client refusera la connexion à tout serveur dont le certificat figure dans cette liste.
    - sslcrldir : (facultatif) correspond au paramètre de connexion sslcrldir , qui précise l’emplacement d’un répertoire contenant des fichiers listant les certificats révoqués. Un client refusera de se connecter à tout serveur dont le certificat figure dans cette liste.
    - sslnegotiation : (facultatif) correspond au paramètre de connexion sslnegotiation , qui contrôle la négociation du chiffrement SSL avec le serveur, le cas échéant.
    - gssencmode : (facultatif) correspond au paramètre de connexion gssencmode , qui détermine si une connexion TCP/IP sécurisée GSS sera négociée avec le serveur, et avec quelle priorité
    - channel_binding : (facultatif) correspond au paramètre de connexion channel_binding , qui contrôle l’utilisation du binding de canal par le client.
- callbacks : scripts d’appel de retour à exécuter lors de certaines actions. Patroni transmettra l’action, le rôle et le nom du cluster. (Voir le fichier scripts/aws.py pour un exemple de mise en œuvre.)
  - on_reload : exécuter ce script lorsqu’une relecture de la configuration est déclenchée.
  - on_restart : exécuter ce script lorsqu’un redémarrage de PostgreSQL est effectué (sans changement de rôle).
  - on_role_change : exécuter ce script lorsqu’un changement de rôle de PostgreSQL est en cours (promotion ou démotion).
  - on_start : exécuter ce script lors du démarrage de PostgreSQL.
  - on_stop : exécuter ce script lors de l’arrêt de PostgreSQL.
- connect_address : adresse IP + port par lequel PostgreSQL est accessible depuis d’autres nœuds et applications.
- proxy_address : adresse IP + port par lequel un pool de connexions (par exemple pgbouncer) en cours d’exécution à côté de Postgres est accessible. La valeur est écrite dans la clé member du DCS sous la forme proxy_url et peut être utilisée utile pour la découverte de services.
- create_replica_methods : une liste ordonnée des méthodes de création pour transformer un nœud Patroni en nouvelle réplique. La méthode par défaut est « basebackup » ; les autres méthodes sont supposées faire référence à des scripts, chacun configuré comme un élément de configuration distinct. Voir la documentation méthodes personnalisées de création de réplique pour plus d’explications.
- data_dir : Emplacement du répertoire de données PostgreSQL, soit existant soit à initialiser par Patroni.
- config_dir : Emplacement du répertoire de configuration de Postgres, par défaut le répertoire de données. Doit être accessible en écriture par Patroni.
- bin_dir : (facultatif) Chemin vers les binaires PostgreSQL (pg_ctl, initdb, pg_controldata, pg_basebackup, postgres, pg_isready, pg_rewind). Si ce paramètre n’est pas fourni ou est une chaîne vide, la variable d’environnement PATH sera utilisée pour localiser les exécutables.
- bin_name : (facultatif) Permet de remplacer les noms des binaires Postgres, si vous utilisez une distribution Postgres personnalisée :
  - pg_ctl : (facultatif) Nom personnalisé pour le binaire pg_ctl.
  - initdb : (facultatif) Nom personnalisé pour le binaire initdb.
  - pgcontroldata : (facultatif) Nom personnalisé pour le binaire pg_controldata.
  - pg_basebackup : (facultatif) Nom personnalisé pour le binaire pg_basebackup.
  - postgres : (facultatif) Nom personnalisé pour le binaire postgres.
  - pg_isready : (facultatif) Nom personnalisé pour le binaire pg_isready.
  - pg_rewind : (facultatif) Nom personnalisé pour le binaire pg_rewind.
- listen : adresse IP + port auxquels Postgres écoute ; doit être accessible depuis les autres nœuds du cluster, si vous utilisez la réplication en flux. Plusieurs adresses séparées par des virgules sont autorisées, à condition que le composant port soit ajouté après la dernière adresse, séparé par deux-points, par exemple listen: 127.0.0.1,127.0.0.2:5432. Patroni utilisera la première adresse de cette liste pour établir des connexions locales vers le nœud PostgreSQL.
- use_unix_socket : indique que Patroni doit privilégier l’utilisation de sockets Unix pour se connecter au cluster. La valeur par défaut est false. Si unix_socket_directories est définie, Patroni utilisera la première valeur adaptée parmi celle-ci pour se connecter au cluster, puis passera à TCP en cas d’indisponibilité. Si unix_socket_directories n’est pas spécifié dans postgresql.parameters, Patroni supposera que la valeur par défaut doit être utilisée et omettra host des paramètres de connexion.
- use_unix_socket_repl : spécifie que Patroni doit privilégier l’utilisation de sockets Unix pour la connexion utilisateur de réplication au cluster. La valeur par défaut est false. Si unix_socket_directories est définie, Patroni utilisera la première valeur adaptée parmi celle-ci pour se connecter au cluster, puis passera à TCP en cas d’absence de valeur adaptée. Si unix_socket_directories n’est pas spécifié dans postgresql.parameters, Patroni supposera que la valeur par défaut doit être utilisée et omettra host des paramètres de connexion.
- pgpass : chemin vers le fichier de mots de passe .pgpass . Patroni crée ce fichier avant d’exécuter pg_basebackup, le script post_init et dans certaines autres circonstances. Le chemin doit être accessible en écriture par Patroni.
- recovery_conf : paramètres de configuration supplémentaires écrits dans recovery.conf lors de la configuration du suiveur.
- custom_conf : chemin vers un fichier postgresql.conf personnalisé facultatif, qui sera utilisé à la place de postgresql.base.conf. Le fichier doit exister sur tous les nœuds du cluster, être lisible par PostgreSQL et sera inclus à partir de son emplacement réel sur postgresql.conf. Notez que Patroni ne surveillera pas ce fichier pour les modifications, ni ne le sauvegardera. Toutefois, ses paramètres peuvent toujours être remplacés par les mécanismes de configuration dynamique de Patroni — voir configuration dynamique pour plus de détails.
- parameters : paramètres de configuration (GUC) pour Postgres au format {ssl: "on", ssl_cert_file: "cert_file"}.
- parameters_primary : (facultatif) substitutions de paramètres spécifiques au rôle pour le primaire. Ces valeurs sont fusionnées avec et remplacent celles du parameters de base.
- parameters_replica : (facultatif) substitutions de paramètres spécifiques au rôle pour la réplique. Ces valeurs sont fusionnées avec et remplacent celles du parameters de base.
- parameters_standby_leader : (facultatif) substitutions de paramètres spécifiques au rôle pour standby_leader. Ces valeurs sont fusionnées avec et remplacent celles du paramètre parameters.
- pg_hba : liste des lignes que Patroni utilisera pour générer pg_hba.conf. Patroni ignore ce paramètre si le paramètre PostgreSQL hba_file possède une valeur différente de celle par défaut. Associé à la configuration dynamique , ce paramètre simplifie la gestion de pg_hba.conf.
  - - host all all 0.0.0.0/0 md5
  - - host replication replicator 127.0.0.1/32 md5 : Une ligne de ce type est obligatoire pour la réplication.
- pg_hba_primary : (facultatif) entrées pg_hba spécifiques au rôle pour le serveur primaire. Elles remplacent entièrement pg_hba (pas de fusion). Si non définies, pg_hba est utilisée.
- pg_hba_replica : (facultatif) entrées pg_hba spécifiques au rôle pour la réplique. Elles remplacent entièrement pg_hba (pas de fusion). Si non définies, pg_hba est utilisée.
- pg_hba_standby_leader : (facultatif) entrées pg_hba spécifiques au rôle pour standby_leader. Elles remplacent entièrement pg_hba (pas de fusion). Si non définies, pg_hba est utilisée.
- pg_ident : liste de lignes que Patroni utilisera pour générer pg_ident.conf. Patroni ignore ce paramètre si le paramètre ident_file PostgreSQL est défini avec une valeur différente de celle par défaut. Ensemble avec configuration dynamique , ce paramètre simplifie la gestion de pg_ident.conf.
  - - mapname1 systemname1 pguser1
  - - mapname1 systemname2 pguser2
- pg_ident_primaire : (facultatif) entrées pg_ident spécifiques aux rôles pour le serveur primaire. Elles remplacent entièrement pg_ident (pas de fusion). Si non définies, pg_ident est utilisée.
- pg_ident_réplique : (facultatif) entrées pg_ident spécifiques aux rôles pour la réplique. Elles remplacent entièrement pg_ident (pas de fusion). Si non définies, pg_ident est utilisée.
- pg_ident_standby_leader : (facultatif) entrées pg_ident spécifiques au rôle pour standby_leader. Elles remplacent entièrement pg_ident (aucune fusion n’est effectuée). Si non définies, pg_ident est utilisée.
- pg_ctl_timeout : Durée d’attente de pg_ctl lors des opérations start, stop ou restart. Valeur par défaut : 60 secondes.
- use_pg_rewind : tenter d’utiliser pg_rewind sur l’ancien leader lorsqu’il rejoint le cluster en tant que réplique. Le cluster doit être initialisé avec data page checksums (--data-checksums pour initdb) et/ou wal_log_hints doit être défini sur on, sinon pg_rewind ne fonctionnera pas.
- rewind : (facultatif) options personnalisées à passer à la commande pg_rewind. Peut être spécifié sous forme de liste de chaînes de caractères et/ou de dictionnaires clé-valeur simples. Les options non autorisées sont : target-pgdata, source-pgdata, source-server, write-recovery-conf, dry-run, restore-target-wal, config-file, no-ensure-shutdown, version, et help. Exemple d’utilisation :
  postgresql: rewind: - debug - progress - sync-method: fsync
- remove_data_directory_on_rewind_failure : Si cette option est activée, Patroni supprime le répertoire de données PostgreSQL et recrée la réplique. Sinon, il tente de suivre le nouveau leader. La valeur par défaut est false.
- remove_data_directory_on_diverged_timelines : Patroni supprimera le répertoire de données PostgreSQL et recréera la réplique si elle détecte une divergence des lignes temporelles et que l’ancien nœud primaire ne peut pas démarrer le streaming depuis le nouveau nœud primaire. Cette option est utile lorsque pg_rewind ne peut pas être utilisée. Lors de la vérification de la divergence des lignes temporelles sur PostgreSQL v10 et les versions antérieures, Patroni tentera de se connecter avec les identifiants de réplication à la base de données « postgres ». Par conséquent, un tel accès doit être autorisé dans pg_hba.conf. La valeur par défaut est false.
- replica_method : pour chaque méthode de création de réplique autre que basebackup, vous devez ajouter une section de configuration du même nom. Cette section doit au minimum inclure “command” avec le chemin complet vers le script réel à exécuter. D’autres paramètres de configuration seront transmis au script sous la forme “paramètre=valeur”.
- pre_promote : un script de fencing qui s’exécute lors d’un basculement, après l’acquisition du verrou leader mais avant la promotion de la réplique. Si le script se termine avec un code différent de zéro, Patroni ne promeut pas la réplique et supprime la clé leader du DCS.
- before_stop : un script qui s’exécute immédiatement avant l’arrêt de postgres. Contrairement à un rappel, ce script s’exécute de manière synchrone, bloquant l’arrêt jusqu’à son achèvement. Le code de retour de ce script n’a pas d’incidence sur la poursuite de l’arrêt.

REST API

restapi :
- thread_pool_size : taille du pool de threads utilisé par Patroni pour traiter les requêtes de l’API REST. La valeur minimale est 5, la valeur par défaut est 5.
- connect_address : adresse IP (ou nom d’hôte) et port permettant d’accéder à l’API REST de Patroni REST API . Tous les membres du cluster doivent pouvoir se connecter à cette adresse, donc sauf si la configuration Patroni est destinée à une démonstration locale, cette adresse ne doit pas être une adresse « localhost » ou de boucle locale (par exemple, « localhost » ou “127.0.0.1”). Elle peut servir d’endpoint pour les vérifications de santé HTTP (voir ci-dessous la configuration du paramètre REST « listen »), ainsi que pour les requêtes utilisateur (directement ou via l’API REST), et pour les vérifications de santé effectuées par les membres du cluster lors des élections du leader (par exemple, pour déterminer si le leader est toujours en cours d’exécution, ou si un nœud possède une position WAL supérieure à celle de l’entité effectuant la requête, etc.). L’adresse connect_address est inscrite dans la clé du membre dans le DCS, ce qui permet de traduire le nom du membre en adresse pour se connecter à son API REST.
- listen : adresse IP (ou nom d’hôte) et port auxquels Patroni écoute pour l’API REST – afin de fournir également les contrôles de santé et la messagerie entre les nœuds participants, comme décrit ci-dessus. Permet de fournir des informations de contrôle de santé à HAProxy (ou tout autre équilibreur de charge capable d’effectuer des vérifications HTTP « OPTION » ou « GET »).
- authentication : (facultatif)
  - username : nom d’utilisateur pour l’authentification basique protégeant les points d’accès de l’API REST non sécurisés.
  - password : mot de passe d’authentification basique pour protéger les points d’entrée de l’API REST non sécurisés.
- certfile : (facultatif) : spécifie le fichier contenant le certificat au format PEM. Si le fichier de certificat n’est pas spécifié ou est vide, le serveur API fonctionnera sans SSL.
- keyfile : (facultatif) : spécifie le fichier contenant la clé secrète au format PEM.
- keyfile_password : (facultatif) : spécifie le mot de passe permettant de déchiffrer le fichier de clé.
- cafile : (facultatif) : Spécifie le fichier contenant le CA_BUNDLE avec les certificats des autorités de certification (CA) de confiance à utiliser lors de la vérification des certificats clients.
- ciphers : (facultatif) : Spécifie les suites de chiffrement autorisées (par exemple « 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: (facultatif) : none (par défaut), optional ou required. Lorsque none est utilisé, l’API REST ne vérifiera pas les certificats clients. Lorsque required est utilisé, les certificats clients sont requis pour toutes les appels à l’API REST. Lorsque optional est utilisé, les certificats clients sont requis pour toutes les finales REST non sécurisées. Lorsque required est utilisé, l’authentification du client réussit si la vérification de la signature du certificat réussit. Pour optional, le certificat client n’est vérifié que pour les requêtes PUT, POST, PATCH et DELETE.
- allowlist : (facultatif) : spécifie l’ensemble des hôtes autorisés à appeler les points de terminaison d’API REST non sécurisés. Chaque élément peut être un nom d’hôte, une adresse IP ou une adresse réseau au format CIDR. Par défaut, allow all est utilisé. Si allowlist ou allowlist_include_members sont définis, tout ce qui n’est pas inclus est rejeté.
- allowlist_include_members : (facultatif) : si défini à true, autorise l’accès à des points de terminaison d’API REST non sécurisés depuis d’autres membres du cluster inscrits dans le DCS (l’adresse IP ou le nom d’hôte est extrait des membres api_url). Prenez garde, il se peut que le système d’exploitation utilise une adresse IP différente pour les connexions sortantes.
- http_extra_headers : (facultatif) : les en-têtes HTTP permettent au serveur d’API REST de transmettre des informations supplémentaires dans une réponse HTTP.
- https_extra_headers : (facultatif) : Les en-têtes HTTPS permettent au serveur de l’API REST de transmettre des informations supplémentaires dans une réponse HTTP lorsque TLS est activé. Cela transmet également les informations supplémentaires définies dans http_extra_headers.
- request_queue_size : (facultatif) : Définit la taille de la file d’attente des requêtes pour la socket TCP utilisée par l’API REST de Patroni. Une fois la file pleine, les requêtes supplémentaires reçoivent une erreur « Connexion refusée ». La valeur par défaut est 5.
- server_tokens: (facultatif) : Configure la valeur de l’en-tête Server HTTP.
  - Minimal : L’en-tête ne contiendra que la version de Patroni, par exemple Patroni/4.0.0.
  - ProductOnly : L’en-tête ne contiendra que le nom du produit, par exemple Patroni.
  - Original (par défaut) : L’en-tête affichera le comportement d’origine et indiquera les versions de BaseHTTP et de Python, par exemple BaseHTTP/0.6 Python/3.12.3.

Voici un exemple des paramètres http_extra_headers et 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'

Avertissement

Le restapi.connect_address doit être accessible depuis tous les nœuds d’un cluster Patroni donné. Internement, Patroni l’utilise pendant la course au leader pour identifier les nœuds présentant un retard de réplication minimal.
Si vous avez activé la validation des certificats clients (restapi.verify_client est défini sur required), vous devez également fournir des certificats clients valides dans les ctl.certfile, ctl.keyfile, ctl.keyfile_password. En l’absence de ces certificats, Patroni ne fonctionnera pas correctement.

CTL

ctl : (facultatif)
- authentication :
  - username : Nom d’utilisateur pour l’authentification basique afin d’accéder aux points de terminaison API REST protégés. Si non fourni, patronictl utilisera la valeur fournie pour le paramètre “username” de l’API REST.
  - password : Mot de passe pour l’authentification basique afin d’accéder aux points de terminaison API REST protégés. Si non fourni, patronictl utilisera la valeur fournie pour le paramètre “password” de l’API REST.
- insecure : autorise les connexions à l’API REST sans vérification des certificats SSL.
- cacert : spécifie le fichier contenant le CA_BUNDLE ou le répertoire contenant les certificats des autorités de certification de confiance à utiliser lors de la vérification des certificats SSL de l’API REST. Si ce paramètre n’est pas fourni, patronictl utilisera la valeur fournie pour le paramètre “cafile” de l’API REST.
- certfile : spécifie le fichier contenant le certificat client au format PEM.
- keyfile : Spécifie le fichier contenant la clé secrète client au format PEM.
- keyfile_password : Spécifie un mot de passe pour déchiffrer le fichier de clé client.

watchdog

mode : off, automatic ou required. Avec off, le watchdog est désactivé. Avec automatic, il est utilisé s’il est disponible et ignoré sinon. Avec required, le nœud ne devient leader que si le watchdog peut être activé.
device : chemin du périphérique watchdog. Valeur par défaut : /dev/watchdog.
safety_margin : marge de sécurité, en secondes, entre le déclenchement du watchdog et l’expiration de la clé de leader.

Balises

clonefrom : true ou false. Si cette option est définie à true, d’autres nœuds pourraient privilégier ce nœud pour l’amorçage (prendre pg_basebackup à partir de). Si plusieurs nœuds ont l’étiquette clonefrom définie à true, le nœud à partir duquel amorcer sera choisi aléatoirement. La valeur par défaut est false.
noloadbalance : true ou false. Si cette option est définie à true, le nœud renvoie le code d’état HTTP 503 pour la vérification de santé de l’API REST GET /replica et est donc exclu de la répartition de charge. Valeur par défaut : false.
replicatefrom : Le nom d’une autre réplique à partir de laquelle effectuer la réplication. Utilisé pour prendre en charge la réplication en cascade.
nosync : true ou false. Si cette option est définie à true, le nœud ne sera jamais sélectionné comme réplique synchrone.
sync_priority : entier, détermine la priorité que ce nœud doit avoir lors de la sélection de la réplique synchrone lorsque synchronous_mode est défini sur on. Les nœuds ayant une priorité plus élevée sont privilégiés par rapport à ceux ayant une priorité plus faible. Si la valeur de sync_priority est 0 ou négative, ce nœud ne peut pas être écrit dans synchronous_standby_names PostgreSQL (similaire à nosync: true). Notez que ce paramètre a une signification opposée à la valeur indiquée dans sync_priority vue dans pg_stat_replication.
nofailover : true ou false, contrôle si ce nœud est autorisé à participer à la course au rôle de leader et à devenir leader. La valeur par défaut est false, ce qui signifie que ce nœud peut_ participer aux courses au rôle de leader.
failover_priority : entier, contrôle la priorité que ce nœud doit avoir lors d’un basculement. Les nœuds ayant une priorité plus élevée sont préférés aux nœuds à priorité plus faible si ceux-ci ont reçu/rejoué la même quantité de WAL. Toutefois, les nœuds ayant une valeur LSN de réception/rejouissance plus élevée sont préférés, quelle que soit leur priorité. Si failover_priority est égal à 0 ou négatif, ce nœud n’est pas autorisé à participer à la course au rôle de leader ni à devenir leader (similaire à nofailover: true). Limitation connue : failover_priority ne fonctionne actuellement pas avec réplication synchrone basée sur le quorum .
nostream : true ou false. Si cette option est définie à true, le nœud n’utilisera pas le protocole de réplication pour diffuser les WAL. Il s’appuiera alors sur la récupération depuis les archives (si restore_command est configuré) ainsi que sur les sondages pg_wal/pg_xlog. Cette configuration désactive également la copie et la synchronisation des slots de réplication logique permanents sur le nœud lui-même et sur toutes ses répliques en cascade. Définir cette option sur un nœud primaire n’a aucun effet.

Avertissement

Renseignez uniquement nofailover ou failover_priority. nofailover: true équivaut à failover_priority: 0, tandis que nofailover: false attribue au nœud la priorité 1.

En plus de ces balises prédéfinies, vous pouvez également ajouter les vôtres :

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

Les balises sont visibles dans l’API REST et dans la commande patronictl_list . Vous pouvez également vérifier l’état d’intégrité d’une instance à l’aide de ces balises. Si la balise n’est pas définie pour une instance, ou si sa valeur respective ne correspond pas à la valeur demandée, le code de statut HTTP renvoyé sera 503.

3 - Paramètres de configuration de l'environnement

Variables d’environnement pour remplacer les paramètres de configuration de Patroni.

Il est possible de remplacer certains paramètres de configuration définis dans le fichier de configuration Patroni à l’aide des variables d’environnement système. Ce document liste toutes les variables d’environnement prises en charge par Patroni. Les valeurs définies via ces variables ont toujours priorité sur celles définies dans le fichier de configuration Patroni.

Global/Universel

PATRONI_CONFIGURATION : il est possible de définir toute la configuration de Patroni via la variable d’environnement PATRONI_CONFIGURATION . Dans ce cas, aucune autre variable d’environnement ne sera prise en compte !
PATRONI_THREAD_POOL_SIZE : taille du pool de threads utilisé par Patroni pour exécuter les tâches asynchrones et communiquer via l’API REST avec les autres membres lors d’une course au leader ou lors de vérifications en mode d’urgence. La valeur minimale est 5, la valeur par défaut est 5.
PATRONI_THREAD_STACK_SIZE : spécifie la taille de pile à utiliser pour les threads lancés par Patroni. La valeur doit être alignée sur 64kB. La valeur minimale est 64kB, la valeur par défaut (définie par Patroni) est 512kB.
PATRONI_NAME : nom du nœud sur lequel l’instance actuelle de Patroni est en cours d’exécution. Doit être unique dans le cluster. La valeur __patroni_strict_sync_replica_placeholder__ est réservée à une utilisation interne par Patroni et ne peut pas être utilisée comme nom de nœud.
PATRONI_NAMESPACE : chemin dans le magasin de configuration où Patroni conservera les informations sur le cluster. Valeur par défaut : “/service”
PATRONI_SCOPE : nom du cluster
PG_MALLOC_ARENA_MAX : valeur personnalisée pour la variable d’environnement MALLOC_ARENA_MAX du processus postmaster. Si non définie, postmaster héritera de la valeur de MALLOC_ARENA_MAX.

Journalisation

PATRONI_LOG_TYPE : définit le format des journaux. Peut être soit plain soit json. Pour utiliser le format json, vous devez avoir installé jsonlogger . La valeur par défaut est plain.
PATRONI_LOG_LEVEL : définit le niveau général de journalisation. La valeur par défaut est INFO (voir la documentation sur le module logging de Python )
PATRONI_LOG_TRACEBACK_LEVEL : définit le niveau auquel les traces d’erreur seront visibles. La valeur par défaut est ERROR. Définissez-la sur DEBUG si vous souhaitez voir les traces d’erreur uniquement lorsque PATRONI_LOG_LEVEL=DEBUG est activé.
PATRONI_LOG_FORMAT : définit la chaîne de formatage des journaux. Si le type de journal est plain, le format doit être une chaîne. Reportez-vous à les attributs LogRecord pour obtenir la liste des attributs disponibles. Si le type de journal est json, le format peut être une liste en plus d’une chaîne. Chaque élément de la liste doit correspondre à un attribut LogRecord. Prenez garde à ce que seul le nom du champ est requis, et que les %( et ) doivent être omis. Si vous souhaitez afficher un champ de journal avec un nom de clé différent, utilisez un dictionnaire où la clé du dictionnaire est le champ de journal, et la valeur est le nom du champ que vous souhaitez afficher dans le journal. Valeur par défaut : %(asctime)s %(levelname)s: %(message)s
PATRONI_LOG_DATEFORMAT : définit la chaîne de formatage de la date et de l’heure. (voir la documentation de formatTime() )
PATRONI_LOG_STATIC_FIELDS : ajoute des champs supplémentaires au journal. Cette option n’est disponible que lorsque le type de journal est défini sur json. Exemple PATRONI_LOG_STATIC_FIELDS="{app: patroni}"
PATRONI_LOG_MAX_QUEUE_SIZE : Patroni utilise une journalisation en deux étapes. Les enregistrements de journal sont écrits dans une file mémoire et un thread distinct extrait ces enregistrements de la file pour les écrire sur stderr ou dans un fichier. La taille maximale de la file interne est limitée par défaut à 1000 enregistrements, ce qui suffit à conserver les journaux des dernières 1h20.
PATRONI_LOG_DIR : Répertoire dans lequel écrire les journaux d’application. Le répertoire doit exister et être accessible en écriture par l’utilisateur exécutant Patroni. Si vous définissez cette variable d’environnement, l’application conservera par défaut 4 fichiers de journaux de 25 Mo chacun. Vous pouvez ajuster ces valeurs de rétention à l’aide de PATRONI_LOG_FILE_NUM et PATRONI_LOG_FILE_SIZE (voir ci-dessous).
PATRONI_LOG_MODE : Permissions des fichiers de journal (par exemple, 0644). Si non spécifié, les permissions seront déterminées en fonction de la valeur actuelle de umask.
PATRONI_LOG_FILE_NUM : Nombre de journaux d’application à conserver.
PATRONI_LOG_FILE_SIZE : Taille du fichier patroni.log (en octets) qui déclenche un roulement du journal.
PATRONI_LOG_LOGGERS : Redéfinir le niveau de journalisation par module Python. Exemple PATRONI_LOG_LOGGERS="{patroni.postmaster: WARNING, urllib3: DEBUG}".
PATRONI_LOG_DEDUPLICATE_HEARTBEAT_LOGS : Si défini à true, les journaux de battement de cœur identiques successifs ne seront pas affichés. La valeur par défaut est false.

[!AVERTISSEMENT]
Le moment auquel la boucle HA s’exécute peut constituer une information très utile pour diagnostiquer les basculements dus à une épuisement des ressources et à des problèmes similaires. Lorsque PATRONI_LOG_DEDUPLICATE_HEARTBEAT_LOGS est défini sur true, aucun journal n’est généré pour l’exécution de la boucle HA (sauf en cas de changement de leader), ce qui fait que cette information potentiellement utile ne sera pas disponible dans les journaux.

Citus

PATRONI_CITUS_GROUP : l’identifiant du groupe Citus, entier. Utilisez 0 pour le coordinateur et 1, 2, etc. pour les workers
PATRONI_CITUS_DATABASE : la base de données où l’extension citus doit être créée. Doit être identique sur le coordinateur et tous les workers. Actuellement, une seule base de données est prise en charge.

Consul

PATRONI_CONSUL_HOST : l’hôte:port de l’agent local Consul.
PATRONI_CONSUL_URL : URL de l’agent local Consul, au format : http(s)://host:port
PATRONI_CONSUL_PORT : (facultatif) port Consul
PATRONI_CONSUL_SCHEME : (facultatif) http ou https, par défaut http
PATRONI_CONSUL_TOKEN : (facultatif) jeton ACL
PATRONI_CONSUL_VERIFY : (facultatif) indique si la vérification du certificat SSL est activée pour les requêtes HTTPS
PATRONI_CONSUL_CACERT : (facultatif) Certificat CA. S’il est présent, l’authentification est activée.
PATRONI_CONSUL_CERT : (facultatif) Fichier contenant le certificat client
PATRONI_CONSUL_KEY : (facultatif) Fichier contenant la clé client. Peut être vide si la clé est incluse dans le certificat.
PATRONI_CONSUL_DC : (facultatif) Centre de données avec lequel établir la communication. Par défaut, le centre de données de l’hôte est utilisé.
PATRONI_CONSUL_CONSISTENCY : (facultatif) Sélectionne le mode de cohérence Consul. Les valeurs possibles sont default, consistent, ou stale (plus de détails dans la référence API Consul consul API reference )
PATRONI_CONSUL_CHECKS : (facultatif) liste des vérifications de santé Consul utilisées pour la session. Par défaut, une liste vide est utilisée.
PATRONI_CONSUL_REGISTER_SERVICE : (facultatif) indique si un service doit être enregistré avec le nom défini par le paramètre scope et l’étiquette master, primary, replica ou standby-leader selon le rôle du nœud. Valeur par défaut : false
PATRONI_CONSUL_SERVICE_TAGS : (facultatif) étiquettes statiques supplémentaires à ajouter au service Consul, en plus du rôle (primary/replica/standby-leader). Par défaut, une liste vide est utilisée.
PATRONI_CONSUL_SERVICE_CHECK_INTERVAL : (facultatif) fréquence à laquelle effectuer la vérification de santé contre l’URL enregistrée
PATRONI_CONSUL_SERVICE_CHECK_TLS_SERVER_NAME : (facultatif) remplacer l’hôte SNI lors de la connexion via TLS, voir également référence de l’API de vérification de l’agent consul .

etcd

PATRONI_ETCD_PROXY : URL du proxy pour etcd. Si vous vous connectez à etcd via un proxy, utilisez ce paramètre à la place de **PATRONI_ETCD_URL
PATRONI_ETCD_URL : URL d’accès à etcd, au format : http(s)://(utilisateur:mot_de_passe@)hôte:port
PATRONI_ETCD_HOSTS : liste des points d’accès etcd au format ‘hôte1:port1’,‘hôte2:port2’, etc…
PATRONI_ETCD_USE_PROXIES : Si ce paramètre est défini sur true, Patroni considérera hosts comme une liste de proxys et n’effectuera pas de découverte de topologie du cluster etcd, mais restera fidèle à la liste fixe de hosts.
PATRONI_ETCD_PROTOCOL : http ou https, si non spécifié, http est utilisé. Si url ou proxy est spécifié, le protocole sera déduit de ces valeurs.
PATRONI_ETCD_HOST : l’hôte:port pour l’endpoint etcd.
PATRONI_ETCD_SRV : Domaine dans lequel rechercher les enregistrements SRV pour la découverte automatique du cluster. Patroni tentera de consulter ces noms de service SRV pour le domaine spécifié (dans cet ordre, jusqu’à la première réussite) : _etcd-client-ssl, _etcd-client, _etcd-ssl, _etcd, _etcd-server-ssl, _etcd-server. Si des enregistrements SRV pour _etcd-server-ssl ou _etcd-server sont récupérés, le protocole pair ETCD sera utilisé pour interroger ETCD afin d’obtenir la liste des membres disponibles. Sinon, les hôtes provenant des enregistrements SRV seront utilisés.
PATRONI_ETCD_SRV_SUFFIX : Configure un suffixe au nom SRV interrogé lors de la découverte. Utilisez cette option pour distinguer plusieurs clusters etcd sous le même domaine. Fonctionne uniquement en conjonction avec PATRONI_ETCD_SRV. Par exemple, si PATRONI_ETCD_SRV_SUFFIX=foo et PATRONI_ETCD_SRV=example.org sont définis, la requête DNS SRV suivante est effectuée : _etcd-client-ssl-foo._tcp.example.com (et ainsi de suite pour chaque nom de service SRV etcd possible).
PATRONI_ETCD_USERNAME : nom d’utilisateur pour l’authentification etcd.
PATRONI_ETCD_PASSWORD : mot de passe pour l’authentification etcd.
PATRONI_ETCD_CACERT : certificat CA. S’il est présent, il active la validation.
PATRONI_ETCD_CERT : fichier contenant le certificat client.
PATRONI_ETCD_KEY : fichier contenant la clé client. Peut être vide si la clé est incluse dans le certificat.

Etcdv3

Les noms d’environnement pour Etcdv3 sont similaires à ceux d’etcd ; il suffit de remplacer ETCD par ETCD3 dans le nom de la variable. Exemple : PATRONI_ETCD3_HOST, PATRONI_ETCD3_CACERT, et ainsi de suite.

[!AVERTISSEMENT]
Les clés créées avec la version 2 du protocole ne sont pas visibles avec la version 3 du protocole, et inversement ; il n’est donc pas possible de passer d’etcd à Etcdv3 en ne mettant à jour que la configuration de Patroni. En outre, Patroni utilise la passerelle gRPC (proxy) d’Etcd pour communiquer avec l’API V3, ce qui empêche l’authentification par nom commun TLS.

ZooKeeper

PATRONI_ZOOKEEPER_HOSTS : Liste séparée par des virgules des membres du cluster ZooKeeper : “‘host1:port1’,‘host2:port2’,’etc…’”. Il est important de citer chaque entité !
PATRONI_ZOOKEEPER_USE_SSL : (facultatif) Indique si le protocole SSL est utilisé. Valeur par défaut : false. Si défini à false, tous les paramètres spécifiques au SSL sont ignorés.
PATRONI_ZOOKEEPER_CACERT : (facultatif) Certificat CA. Si présent, active la validation.
PATRONI_ZOOKEEPER_CERT : (facultatif) Fichier contenant le certificat client.
PATRONI_ZOOKEEPER_KEY : (facultatif) Fichier contenant la clé client.
PATRONI_ZOOKEEPER_KEY_PASSWORD : (facultatif) Mot de passe de la clé client.
PATRONI_ZOOKEEPER_VERIFY : (facultatif) Indique si la vérification du certificat doit être effectuée ou non. Valeur par défaut : true.
PATRONI_ZOOKEEPER_SET_ACLS : (facultatif) Si défini, configure Kazoo pour appliquer une ACL par défaut à chaque ZNode qu’il crée. Les ACL peuvent utiliser le schéma x509 (par défaut) ou d’autres schémas pris en charge par ZooKeeper, tels que digest. Elles doivent être spécifiées sous forme de dictionnaire, où la clé est le principal complet (éventuellement préfixé par le schéma) et la valeur une liste de permissions. Les permissions peuvent être une ou plusieurs des valeurs suivantes : CREATE, READ, WRITE, DELETE, ADMIN, ou ALL. Par exemple, set_acls: {CN=principal1: [CREATE, READ], digest:principal2:+pjROuBuuwNNSujKyH8dGcEnFPQ=: [ALL]}.
PATRONI_ZOOKEEPER_AUTH_DATA : (facultatif) Informations d’authentification à utiliser pour la connexion. Doit être un dictionnaire dont scheme est la clé et credential la valeur. Valeur par défaut : dictionnaire vide.

Note

Il est obligatoire d’installer kazoo>=2.6.0 pour prendre en charge le SSL.

Exposant

PATRONI_EXHIBITOR_HOSTS : liste initiale des nœuds Exhibitor (ZooKeeper) au format : ‘hôte1,hôte2,etc…’. Cette liste est mise à jour automatiquement chaque fois que la topologie du cluster Exhibitor (ZooKeeper) change.
PATRONI_EXHIBITOR_PORT : port Exhibitor.

Kubernetes

PATRONI_KUBERNETES_BYPASS_API_SERVICE : (facultatif) Lors de la communication avec l’API Kubernetes, Patroni utilise généralement le service kubernetes , dont l’adresse est exposée dans les pods via la variable d’environnement KUBERNETES_SERVICE_HOST. Si PATRONI_KUBERNETES_BYPASS_API_SERVICE est défini sur true, Patroni résout la liste des nœuds API derrière le service et se connecte directement à ceux-ci.
PATRONI_KUBERNETES_NAMESPACE : (facultatif) Espace de noms Kubernetes dans lequel s’exécute le pod Patroni. Valeur par défaut : default.
PATRONI_KUBERNETES_LABELS : Étiquettes au format {label1: value1, label2: value2}. Ces étiquettes seront utilisées pour localiser les objets existants (Pods et soit des Endpoints, soit des ConfigMaps) associés au cluster actuel. Patroni les définira également sur chaque objet (Endpoint ou ConfigMap) qu’il crée.
PATRONI_KUBERNETES_SCOPE_LABEL : (facultatif) nom de l’étiquette contenant le nom du cluster. La valeur par défaut est cluster-name.
PATRONI_KUBERNETES_BOOTSTRAP_LABELS : (facultatif) Étiquettes au format {label1: value1, label2: value2}. Ces étiquettes seront attribuées au pod Patroni lorsque son état est l’un des suivants : initializing new cluster, running custom bootstrap script, starting after custom bootstrap ou creating replica.
PATRONI_KUBERNETES_ROLE_LABEL : (facultatif) nom de l’étiquette contenant le rôle (primary, replica ou autre valeur personnalisée). Patroni définira cette étiquette sur le pod dans lequel il s’exécute. Valeur par défaut : role.
PATRONI_KUBERNETES_LEADER_LABEL_VALUE : (facultatif) valeur de l’étiquette du pod lorsque le rôle PostgreSQL est primary. Valeur par défaut : primary.
PATRONI_KUBERNETES_FOLLOWER_LABEL_VALUE : (facultatif) valeur de l’étiquette du pod lorsque le rôle PostgreSQL est replica. Valeur par défaut : replica.
PATRONI_KUBERNETES_STANDBY_LEADER_LABEL_VALUE : (facultatif) valeur de l’étiquette du pod lorsque le rôle Postgres est standby_leader. Valeur par défaut : primary.
PATRONI_KUBERNETES_TMP_ROLE_LABEL : (facultatif) nom de l’étiquette temporaire contenant le rôle (primary ou replica). La valeur de cette étiquette utilisera toujours la valeur par défaut correspondante au rôle. À définir uniquement si nécessaire.
PATRONI_KUBERNETES_USE_ENDPOINTS : (facultatif) si défini à true, Patroni utilisera des Endpoints au lieu de ConfigMaps pour effectuer les élections du leader et maintenir l’état du cluster.
PATRONI_KUBERNETES_POD_IP : (facultatif) adresse IP du pod dans lequel Patroni s’exécute. Cette valeur est requise lorsque PATRONI_KUBERNETES_USE_ENDPOINTS est activé et est utilisée pour remplir les sous-ensembles de l’endpoint leader lorsque le pod PostgreSQL est promu.
PATRONI_KUBERNETES_PORTS : (facultatif) si l’objet Service possède un nom pour le port, ce même nom doit apparaître dans l’objet Endpoint, sinon le service ne fonctionnera pas. Par exemple, si votre service est défini comme {Kind: Service, spec: {ports: [{name: postgresql, port: 5432, targetPort: 5432}]}}, vous devez définir PATRONI_KUBERNETES_PORTS='[{"name": "postgresql", "port": 5432}]' et Patroni l’utilisera pour mettre à jour les sous-ensembles de l’Endpoint leader. Ce paramètre n’est utilisé que si PATRONI_KUBERNETES_USE_ENDPOINTS est défini.
PATRONI_KUBERNETES_CACERT : (facultatif) indique le fichier CA_BUNDLE contenant les certificats des autorités de certification approuvées pour vérifier les certificats SSL de l’API Kubernetes. En l’absence de valeur, Patroni utilise celle du secret ServiceAccount.
PATRONI_RETRIABLE_HTTP_CODES : (facultatif) liste des codes d’état HTTP de l’API K8s pour lesquels une nouvelle tentative doit être effectuée. Par défaut, Patroni réessaie pour 500, 503 et 504, ou lorsque la réponse de l’API K8s contient l’en-tête HTTP retry-after.

Raft (obsolète)

PATRONI_RAFT_SELF_ADDR: ip:port sur lequel écouter pour les connexions Raft. L’self_addr doit être accessible depuis les autres nœuds du cluster. Si non définie, le nœud ne participera pas au consensus.
PATRONI_RAFT_BIND_ADDR: (facultatif) ip:port sur lequel écouter pour les connexions Raft. Si non spécifié, l’self_addr sera utilisé.
PATRONI_RAFT_PARTNER_ADDRS: liste des autres nœuds Patroni du cluster au format "'ip1:port1','ip2:port2'". Il est important de citer chaque entité entre guillemets !
PATRONI_RAFT_DATA_DIR : répertoire dans lequel stocker les journaux Raft et les instantanés. Si non spécifié, le répertoire de travail actuel est utilisé.
PATRONI_RAFT_PASSWORD : (facultatif) Chiffrer le trafic Raft avec un mot de passe spécifié, nécessite le module cryptography Python.
PATRONI_RAFT_MIN_TIMEOUT : (facultatif) délai minimum d’élection en secondes pour l’implémentation Raft pysyncobj sous-jacente. Doit être supérieur à 3 × PATRONI_RAFT_APPEND_ENTRIES_PERIOD. Valeur par défaut : 0.4.
PATRONI_RAFT_MAX_TIMEOUT : (facultatif) délai maximal d’élection en secondes pour l’implémentation Raft underlying pysyncobj. Doit être supérieur à PATRONI_RAFT_MIN_TIMEOUT. Valeur par défaut : 1.4.
PATRONI_RAFT_CONNECTION_TIMEOUT : (facultatif) délai en secondes après lequel une connexion sans données reçues est considérée comme inactive. Doit être supérieur ou égal à PATRONI_RAFT_MAX_TIMEOUT. Valeur par défaut : 3.5.
PATRONI_RAFT_APPEND_ENTRIES_PERIOD : (facultatif) intervalle en secondes pour l’envoi des commandes de battement de cœur. Doit être inférieur à un tiers de PATRONI_RAFT_MIN_TIMEOUT. Valeur par défaut : 0.1.
PATRONI_RAFT_CONNECTION_RETRY_TIME : (facultatif) intervalle en secondes entre les tentatives de reconnexion aux nœuds hors ligne. Valeur par défaut : 5.0.
PATRONI_RAFT_LEADER_FALLBACK_TIMEOUT : (facultatif) durée en secondes après laquelle un leader ne recevant aucune réponse de la majorité redevient un suiveur. Doit être supérieur à PATRONI_RAFT_APPEND_ENTRIES_PERIOD. Valeur par défaut : 30.0.

Note

Patroni vérifie ces contraintes au démarrage et refusera de démarrer si elles sont violées. Ces valeurs ne peuvent pas être modifiées en cours d’exécution et nécessitent une redémarrage. Pour plus de détails, y compris la limitation liée aux latences élevées, consultez Paramètres Raft .

PostgreSQL

PATRONI_POSTGRESQL_LISTEN : adresse IP + port auxquels Postgres écoute. Plusieurs adresses séparées par des virgules sont autorisées, à condition que le composant port soit ajouté après la dernière adresse, séparé par deux-points, c’est-à-dire listen: 127.0.0.1,127.0.0.2:5432. Patroni utilisera la première adresse de cette liste pour établir des connexions locales vers le nœud PostgreSQL.
PATRONI_POSTGRESQL_CONNECT_ADDRESS : adresse IP + port par lequel Postgres est accessible depuis d’autres nœuds et applications.
PATRONI_POSTGRESQL_PROXY_ADDRESS : adresse IP + port par lequel un pool de connexions (par exemple pgbouncer) en cours d’exécution à côté de Postgres est accessible. La valeur est écrite dans la clé member du DCS sous la forme proxy_url et peut être utilisée/utilisée pour la découverte de services.
PATRONI_POSTGRESQL_DATA_DIR : emplacement du répertoire de données Postgres, existant ou à initialiser par Patroni.
PATRONI_POSTGRESQL_CONFIG_DIR : Emplacement du répertoire de configuration de Postgres, par défaut le répertoire de données. Doit être accessible en écriture par Patroni.
PATRONI_POSTGRESQL_BIN_DIR : Chemin vers les binaires de PostgreSQL (pg_ctl, initdb, pg_controldata, pg_basebackup, postgres, pg_isready, pg_rewind). La valeur par défaut est une chaîne vide, ce qui signifie que les exécutables seront recherchés dans la variable d’environnement PATH.
PATRONI_POSTGRESQL_BIN_PG_CTL : (facultatif) Nom personnalisé pour le binaire pg_ctl.
PATRONI_POSTGRESQL_BIN_INITDB : (facultatif) Nom personnalisé pour le binaire initdb.
PATRONI_POSTGRESQL_BIN_PG_CONTROLDATA : (facultatif) Nom personnalisé pour le binaire pg_controldata.
PATRONI_POSTGRESQL_BIN_PG_BASEBACKUP : (facultatif) Nom personnalisé pour le binaire pg_basebackup.
PATRONI_POSTGRESQL_BIN_POSTGRES : (facultatif) Nom personnalisé pour le binaire postgres.
PATRONI_POSTGRESQL_BIN_IS_READY : (facultatif) Nom personnalisé pour le binaire pg_isready.
PATRONI_POSTGRESQL_BIN_PG_REWIND : (facultatif) Nom personnalisé pour le binaire pg_rewind.
PATRONI_POSTGRESQL_PGPASS : chemin vers le fichier de mot de passe .pgpass . Patroni crée ce fichier avant d’exécuter pg_basebackup et dans certaines autres circonstances. Le répertoire doit être accessible en écriture par Patroni.
PATRONI_REPLICATION_USERNAME : nom d’utilisateur de réplication ; l’utilisateur sera créé lors de l’initialisation. Les répliques utiliseront cet utilisateur pour accéder à la source de réplication via la réplication en flux
PATRONI_REPLICATION_PASSWORD : mot de passe de réplication ; l’utilisateur sera créé lors de l’initialisation.
PATRONI_REPLICATION_SSLMODE : (facultatif) correspond au paramètre de connexion sslmode , qui permet à un client de spécifier le mode de négociation TLS avec le serveur. Pour plus d’informations sur le fonctionnement de chaque mode, veuillez consulter la documentation PostgreSQL . Le mode par défaut est prefer.
PATRONI_REPLICATION_SSLKEY : (facultatif) mappe au paramètre de connexion sslkey , qui précise l’emplacement de la clé secrète utilisée avec le certificat client.
PATRONI_REPLICATION_SSLPASSWORD : (facultatif) correspond au paramètre de connexion sslpassword , qui précise le mot de passe de la clé secrète spécifiée dans PATRONI_REPLICATION_SSLKEY.
PATRONI_REPLICATION_SSLCERT : (facultatif) correspond au paramètre de connexion sslcert , qui précise l’emplacement du certificat client.
PATRONI_REPLICATION_SSLROOTCERT : (facultatif) correspond au paramètre de connexion sslrootcert , qui précise l’emplacement d’un fichier contenant un ou plusieurs certificats d’autorités de certification (CA) utilisés par le client pour vérifier le certificat d’un serveur.
PATRONI_REPLICATION_SSLCRL : (facultatif) correspond au paramètre de connexion sslcrl , qui précise l’emplacement d’un fichier contenant une liste de révocation de certificats. Un client refusera la connexion à tout serveur dont le certificat figure dans cette liste.
PATRONI_REPLICATION_SSLCRLDIR : (facultatif) correspond au paramètre de connexion sslcrldir , qui précise l’emplacement d’un répertoire contenant des fichiers listant les certificats révoqués. Un client refusera de se connecter à tout serveur dont le certificat figure dans cette liste.
PATRONI_REPLICATION_SSLNEGOTIATION : (facultatif) correspond au paramètre de connexion sslnegotiation , qui contrôle la négociation du chiffrement SSL avec le serveur, le cas échéant.
PATRONI_REPLICATION_GSSENCMODE : (facultatif) correspond au paramètre de connexion gssencmode , qui détermine si une connexion TCP/IP sécurisée GSS sera négociée avec le serveur, et avec quelle priorité
PATRONI_REPLICATION_CHANNEL_BINDING : (facultatif) correspond au paramètre de connexion channel_binding , qui contrôle l’utilisation du binding de canal par le client.
PATRONI_SUPERUSER_USERNAME : nom de l’utilisateur superutilisateur, défini lors de l’initialisation (initdb) et utilisé ultérieurement par Patroni pour se connecter à PostgreSQL. Cet utilisateur est également utilisé par pg_rewind.
PATRONI_SUPERUSER_PASSWORD : mot de passe pour l’utilisateur superutilisateur, défini lors de l’initialisation (initdb).
PATRONI_SUPERUSER_SSLMODE : (facultatif) correspond au paramètre de connexion sslmode , qui permet à un client de spécifier le mode de négociation TLS avec le serveur. Pour plus d’informations sur le fonctionnement de chaque mode, veuillez consulter la documentation PostgreSQL . Le mode par défaut est prefer.
PATRONI_SUPERUSER_SSLKEY : (facultatif) mappe au paramètre de connexion sslkey , qui précise l’emplacement de la clé secrète utilisée avec le certificat client.
PATRONI_SUPERUSER_SSLPASSWORD : (facultatif) correspond au paramètre de connexion sslpassword , qui précise le mot de passe de la clé secrète spécifiée dans PATRONI_SUPERUSER_SSLKEY.
PATRONI_SUPERUSER_SSLCERT : (facultatif) correspond au paramètre de connexion sslcert , qui précise l’emplacement du certificat client.
PATRONI_SUPERUSER_SSLROOTCERT : (facultatif) correspond au paramètre de connexion sslrootcert , qui précise l’emplacement d’un fichier contenant un ou plusieurs certificats d’autorités de certification (CA) utilisés par le client pour vérifier le certificat d’un serveur.
PATRONI_SUPERUSER_SSLCRL : (facultatif) correspond au paramètre de connexion sslcrl , qui précise l’emplacement d’un fichier contenant une liste de révocation de certificats. Un client refusera la connexion à tout serveur dont le certificat figure dans cette liste.
PATRONI_SUPERUSER_SSLCRLDIR : (facultatif) mappe au paramètre de connexion sslcrldir , qui précise l’emplacement d’un répertoire contenant des fichiers listant les certificats révoqués. Un client refusera de se connecter à tout serveur dont le certificat figure dans cette liste.
PATRONI_SUPERUSER_SSLNEGOTIATION : (facultatif) correspond au paramètre de connexion sslnegotiation , qui contrôle la négociation du chiffrement SSL avec le serveur, le cas échéant.
PATRONI_SUPERUSER_GSSENCMODE : (facultatif) correspond au paramètre de connexion gssencmode , qui détermine si une connexion TCP/IP sécurisée GSS sera négociée avec le serveur, et avec quelle priorité
PATRONI_SUPERUSER_CHANNEL_BINDING : (facultatif) correspond au paramètre de connexion channel_binding , qui contrôle l’utilisation du lien de canal par le client.
PATRONI_REWIND_USERNAME : (facultatif) nom de l’utilisateur pour pg_rewind ; l’utilisateur sera créé lors de l’initialisation de PostgreSQL 11+ et toutes les autorisations nécessaires lui seront accordées.
PATRONI_REWIND_PASSWORD : (facultatif) mot de passe de l’utilisateur pour pg_rewind ; l’utilisateur sera créé lors de l’initialisation.
PATRONI_REWIND_SSLMODE : (facultatif) correspond au paramètre de connexion sslmode , qui permet à un client de spécifier le mode de négociation TLS avec le serveur. Pour plus d’informations sur le fonctionnement de chaque mode, veuillez consulter la documentation PostgreSQL . Le mode par défaut est prefer.
PATRONI_REWIND_SSLKEY : (facultatif) correspond au paramètre de connexion sslkey , qui précise l’emplacement de la clé secrète utilisée avec le certificat client.
PATRONI_REWIND_SSLPASSWORD : (facultatif) correspond au paramètre de connexion sslpassword , qui précise le mot de passe de la clé secrète spécifiée dans PATRONI_REWIND_SSLKEY.
PATRONI_REWIND_SSLCERT : (facultatif) correspond au paramètre de connexion sslcert , qui précise l’emplacement du certificat client.
PATRONI_REWIND_SSLROOTCERT : (facultatif) correspond au paramètre de connexion sslrootcert , qui précise l’emplacement d’un fichier contenant un ou plusieurs certificats d’autorités de certification (CA) utilisés par le client pour vérifier le certificat d’un serveur.
PATRONI_REWIND_SSLCRL : (facultatif) mappe au paramètre de connexion sslcrl , qui précise l’emplacement d’un fichier contenant une liste de révocation de certificats. Un client refusera de se connecter à tout serveur dont le certificat figure dans cette liste.
PATRONI_REWIND_SSLCRLDIR : (facultatif) correspond au paramètre de connexion sslcrldir , qui précise l’emplacement d’un répertoire contenant des fichiers listant les certificats révoqués. Un client refusera de se connecter à tout serveur dont le certificat figure dans cette liste.
PATRONI_REWIND_SSLNEGOTIATION : (facultatif) correspond au paramètre de connexion sslnegotiation , qui contrôle la négociation du chiffrement SSL avec le serveur, le cas échéant.
PATRONI_REWIND_GSSENCMODE : (facultatif) correspond au paramètre de connexion gssencmode , qui détermine si une connexion TCP/IP sécurisée GSS sera négociée avec le serveur, et avec quelle priorité
PATRONI_REWIND_CHANNEL_BINDING : (facultatif) correspond au paramètre de connexion channel_binding , qui contrôle l’utilisation du lien de canal par le client.

REST API

PATRONI_RESTAPI_THREAD_POOL_SIZE : taille du pool de threads utilisé par Patroni pour traiter les requêtes de l’API REST. La valeur minimale est 5, la valeur par défaut est 5.
PATRONI_RESTAPI_CONNECT_ADDRESS : adresse IP et port d’accès à l’API REST.
PATRONI_RESTAPI_LISTEN : adresse IP et port auxquels Patroni écoute, afin de fournir des informations de santé-check pour HAProxy.
PATRONI_RESTAPI_USERNAME : nom d’utilisateur pour l’authentification basique protégeant les points d’accès de l’API REST non sécurisés.
PATRONI_RESTAPI_PASSWORD : Mot de passe d’authentification basique pour protéger les points de terminaison API REST non sécurisés.
PATRONI_RESTAPI_CERTFILE : Spécifie le fichier contenant le certificat au format PEM. Si le fichier de certificat n’est pas précisé ou est vide, le serveur API fonctionnera sans SSL.
PATRONI_RESTAPI_KEYFILE : Spécifie le fichier contenant la clé secrète au format PEM.
PATRONI_RESTAPI_KEYFILE_PASSWORD : Spécifie le mot de passe pour déchiffrer le fichier de clé.
PATRONI_RESTAPI_CAFILE : indique le fichier CA_BUNDLE contenant les certificats des autorités de certification approuvées pour vérifier les certificats clients.
PATRONI_RESTAPI_CIPHERS : (facultatif) indique les suites de chiffrement autorisées, par exemple “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 (par défaut), optional ou required. Lorsque none est utilisé, l’API REST ne vérifiera pas les certificats clients. Lorsque required est utilisé, les certificats clients sont requis pour toutes les appels à l’API REST. Lorsque optional est utilisé, les certificats clients sont requis pour toutes les finitions REST non sécurisées. Lorsque required est utilisé, l’authentification du client réussit si la vérification de la signature du certificat réussit. Pour optional, le certificat client n’est vérifié que pour les requêtes PUT, POST, PATCH et DELETE.
PATRONI_RESTAPI_ALLOWLIST : (facultatif) : Spécifie l’ensemble des hôtes autorisés à appeler les points de terminaison d’API REST non sécurisés. Chaque élément peut être un nom d’hôte, une adresse IP ou une adresse réseau au format CIDR. Par défaut, allow all est utilisé. Si allowlist ou allowlist_include_members sont définis, tout ce qui n’est pas inclus est rejeté.
PATRONI_RESTAPI_ALLOWLIST_INCLUDE_MEMBERS : (facultatif) Si défini à true, permet d’accéder à des points de terminaison d’API REST non sécurisés depuis d’autres membres du cluster inscrits dans le DCS (l’adresse IP ou le nom d’hôte est extrait des membres api_url). Prenez garde, il se peut que le système d’exploitation utilise une adresse IP différente pour les connexions sortantes.
PATRONI_RESTAPI_HTTP_EXTRA_HEADERS : (facultatif) Les en-têtes HTTP permettent au serveur d’API REST de transmettre des informations supplémentaires dans une réponse HTTP.
PATRONI_RESTAPI_HTTPS_EXTRA_HEADERS : (facultatif) Les en-têtes HTTPS permettent au serveur d’API REST de transmettre des informations supplémentaires dans une réponse HTTP lorsque TLS est activé. Cela transmet également les informations supplémentaires définies dans http_extra_headers.
PATRONI_RESTAPI_REQUEST_QUEUE_SIZE : (facultatif) Définit la taille de la file d’attente des requêtes pour la socket TCP utilisée par l’API REST de Patroni. Dès que la file est pleine, les requêtes supplémentaires reçoivent une erreur « Connexion refusée ». La valeur par défaut est 5.
PATRONI_RESTAPI_SERVER_TOKENS : (facultatif) Configure la valeur de l’en-tête HTTP Server. Original (par défaut) conserve le comportement original et affiche les versions de BaseHTTP et de Python, par exemple BaseHTTP/0.6 Python/3.12.3. Minimal : l’en-tête ne contiendra que la version de Patroni, par exemple Patroni/4.0.0. ProductOnly : l’en-tête ne contiendra que le nom du produit, par exemple Patroni.

Avertissement

Le PATRONI_RESTAPI_CONNECT_ADDRESS doit être accessible depuis tous les nœuds d’un cluster Patroni donné. Internement, Patroni l’utilise lors de la course au leader pour identifier les nœuds présentant un retard de réplication minimal.
Si vous avez activé la validation des certificats client (PATRONI_RESTAPI_VERIFY_CLIENT est défini sur required), vous devez également fournir des certificats clients valides dans les PATRONI_CTL_CERTFILE, PATRONI_CTL_KEYFILE, PATRONI_CTL_KEYFILE_PASSWORD. En l’absence de ces certificats, Patroni ne fonctionnera pas correctement.

CTL

PATRONICTL_CONFIG_FILE : (facultatif) emplacement du fichier de configuration.
PATRONI_CTL_USERNAME : (facultatif) nom d’utilisateur pour l’authentification basique afin d’accéder aux points de terminaison protégés de l’API REST. Si non fourni, patronictl utilisera la valeur fournie pour le paramètre « username » de l’API REST.
PATRONI_CTL_PASSWORD : (facultatif) Mot de passe d’authentification basique pour accéder aux points de terminaison protégés de l’API REST. Si non fourni, patronictl utilisera la valeur fournie pour le paramètre « password » de l’API REST.
PATRONI_CTL_INSECURE : (facultatif) Autoriser les connexions à l’API REST sans vérification des certificats SSL.
PATRONI_CTL_CACERT : (facultatif) indique le fichier CA_BUNDLE ou le répertoire contenant les certificats des autorités de certification approuvées pour vérifier les certificats SSL de l’API REST. En l’absence de valeur, patronictl utilise le paramètre “cafile” de l’API REST.
PATRONI_CTL_CERTFILE : (facultatif) indique le fichier du certificat client au format PEM.
PATRONI_CTL_KEYFILE : (facultatif) indique le fichier de la clé secrète du client au format PEM.
PATRONI_CTL_KEYFILE_PASSWORD : (facultatif) Spécifie un mot de passe pour décrypter le fichier de clé client.