Documentation Patroni 4.1.5

• 1: Introduction
• 2: Installation
• 3: Configuration Patroni
  • 3.1: Paramètres de configuration dynamique
  • 3.2: Paramètres de configuration YAML
  • 3.3: Paramètres de configuration de l'environnement
• 4: API REST Patroni
• 5: patronictl
• 6: Imagerie de réplique et amorçage
• 7: Modes de réplication
• 8: cluster de secours
• 9: Prise en charge du watchdog
• 10: Mode Pause/Reprise pour le cluster
• 11: Mode de secours DCS
• 12: Utilisation de Patroni avec Kubernetes
• 13: Prise en charge Citus
• 14: Convertir un nœud autonome en cluster Patroni
• 15: Intégration avec d'autres outils
• 16: Considérations de sécurité
• 17: Haute disponibilité multi-centre de données
• 18: FAQ
• 19: Notes de version
• 20: Guidelines pour les contributions

[!AVERTISSEMENT]

Exécution de Patroni sur des systèmes à mémoire limitée avec Python 3.11+

Si vous exécutez Patroni sur un système avec des limites de mémoire strictes, par exemple avec vm.overcommit_memory=2 (recommandé pour PostgreSQL), et utilisez Python 3.11 ou une version ultérieure, vous pouvez observer un comportement inattendu :

• Patroni est en état sain
• PostgreSQL continue de s’exécuter
• L’API REST de Patroni devient inopérante
• Le système d’exploitation indique que Patroni écoute sur le port de l’API REST
• Les journaux de Patroni semblent normaux ; cependant, les messages suivants peuvent apparaître une fois : Exception ignored in thread started by: <object repr() failed>, MemoryError
• Les journaux du noyau peuvent contenir des messages tels que not enough memory for the allocation

Ce comportement est dû à un bug dans Python 3.11+ . Sous des conditions de mémoire strictes, le démarrage d’un nouveau thread peut bloquer indéfiniment en l’absence de mémoire libre.

Solution recommandée

Les versions récentes de Patroni (4.1.1+, 4.0.8+) réduisent l’impact de ce problème en lançant tous les threads requis dès le démarrage, avant que le système ne soit soumis à une pression mémoire.

Recommandations supplémentaires (Linux, glibc)

Lors de l’exécution avec vm.overcommit_memory=2 (recommandé pour PostgreSQL), nous recommandons également de lancer Patroni avec les variables d’environnement suivantes configurées :

• MALLOC_ARENA_MAX=1 - réduit la quantité de mémoire virtuelle allouée par glibc aux applications multithreadées
• PG_MALLOC_ARENA_MAX= - réinitialise la valeur de MALLOC_ARENA_MAX pour les processus PostgreSQL lancés par Patroni.

En outre, vous pouvez ajuster les paramètres de configuration suivants de Patroni :

• thread_stack_size - taille de la pile utilisée par les threads lancés par Patroni. Réduire cette valeur diminue l’utilisation mémoire du processus Patroni. La valeur par défaut définie par Patroni est 512kB. Augmentez thread_stack_size si Patroni subit des plantages liés à la pile ; sinon, la valeur par défaut est suffisante.
• thread_pool_size - taille du pool de threads utilisé par Patroni pour les tâches asynchrones et la communication API REST avec les autres membres lors des courses au leader ou des vérifications en mode d’urgence. La valeur par défaut est 5, qui est suffisante pour les clusters à trois nœuds.
• restapi.thread_pool_size - taille du pool de threads utilisé pour traiter les requêtes API REST. La valeur par défaut est 5, permettant jusqu’à cinq requêtes API REST en parallèle. Notez que les requêtes impliquant des requêtes SQL sont effectivement sérialisées, car une seule connexion à la base de données est utilisée, aussi l’augmentation de cette valeur ne procure généralement aucun avantage.

---

Patroni est un modèle de solutions PostgreSQL à haute disponibilité (HA) basé sur Python. Pour une accessibilité maximale, Patroni prend en charge une variété de magasins de configuration distribués, tels que ZooKeeper , etcd , Consul ou Kubernetes . Les ingénieurs base de données, les DBA, les ingénieurs DevOps et les SRE qui souhaitent déployer rapidement une solution PostgreSQL à haute disponibilité dans des datacenters — ou ailleurs — devraient y trouver un intérêt.

Nous appelons Patroni un « modèle » car il est loin d’être un système de réplication universel ou immédiatement utilisable. Il présente ses propres contraintes. À utiliser avec prudence. Il existe de nombreuses façons de mettre en œuvre une haute disponibilité avec PostgreSQL ; pour en consulter la liste, reportez-vous à la Documentation PostgreSQL .

Versions de PostgreSQL actuellement prises en charge : 9.3 à 18.

Remarque aux utilisateurs de Citus : À compter de la version 3.0, Patroni intègre harmonieusement l’extension de base de données Citus pour PostgreSQL. Veuillez consulter la page Prise en charge de Citus dans la documentation de Patroni pour plus d’informations sur l’utilisation de la haute disponibilité Patroni avec un cluster distribué Citus.

Remarque aux utilisateurs Kubernetes : Patroni peut s’exécuter nativement sur Kubernetes. Consultez le chapitre Kubernetes de la documentation Patroni.

1 - Introduction

Patroni est un modèle de solutions PostgreSQL à haute disponibilité (HA) basé sur Python. Patroni a été initialement développé à partir d’une branche de Governor , le projet de Compose. Il intègre de nombreuses fonctionnalités nouvelles.

Pour plus d’informations de contexte, voir :

• Haute disponibilité PostgreSQL avec Kubernetes et Patroni , conférence de Josh Berkus à KubeCon 2016 (vidéo)
• Article du blog technique Zalando, février 2016

Statut de développement

Patroni est en développement actif et accepte les contributions. Consultez notre section Contributing ci-dessous pour plus de détails.

Nous signalons les informations sur les nouvelles versions ici .

Exigences techniques/Installation

Aller à here pour obtenir des instructions sur l’installation et la mise à jour de Patroni sur diverses plates-formes.

Planification du nombre de nœuds PostgreSQL

Les nœuds Patroni/PostgreSQL sont déconnectés des nœuds DCS (sauf lorsque Patroni implémente lui-même RAFT) et il n’existe donc aucune exigence concernant le nombre minimal de nœuds. Exécuter un cluster composé d’un nœud primaire et d’un nœud en veille est tout à fait acceptable. Vous pouvez ajouter davantage de nœuds en veille ultérieurement.

Clusters à 2 nœuds (primaire + secondaire) sont courants et offrent un basculement automatique avec une haute disponibilité. Notez qu’en cas de basculement, vous aurez temporairement une absence de redondance jusqu’à ce que le nœud défaillant se reconnecte.

Exigences du DCS : Votre DCS (etcd, ZooKeeper, Consul) doit fonctionner avec 3 ou 5 nœuds pour assurer un consensus correct et une tolérance aux pannes. Un seul cluster DCS peut stocker des informations pour des centaines ou des milliers de clusters Patroni en utilisant différentes combinaisons d’espace de noms (namespace) ou de portée (scope).

Exécution et configuration

La section suivante suppose que le dépôt Patroni a été cloné à partir de https://github.com/patroni/patroni . Vous aurez besoin des fichiers de configuration exemple postgres0.yml et postgres1.yml. Si vous avez installé Patroni avec pip, vous pouvez obtenir ces fichiers à partir du dépôt git et remplacer ./patroni.py ci-dessous par la commande patroni.

Pour commencer, effectuez les opérations suivantes depuis des terminaux distincts :

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

Vous verrez alors un cluster à haute disponibilité démarrer. Testez différents paramètres dans les fichiers YAML pour observer les changements de comportement du cluster. Mettez hors service certains composants pour observer le comportement du système.

Ajoutez davantage de fichiers postgres*.yml pour créer un cluster encore plus grand.

Patroni fournit une configuration HAProxy , qui permet à votre application de se connecter au leader du cluster via un seul point d’accès. Pour la configurer, exécutez :

> haproxy -f haproxy.cfg

> psql --host 127.0.0.1 --port 5000 postgres

Configuration YAML

Aller à here pour obtenir des informations complètes sur les paramètres d’etcd, consul et ZooKeeper. Pour un exemple, voir postgres0.yml .

Configuration de l’environnement

Accédez à ici pour obtenir des informations complètes sur la configuration (remplacement) des paramètres via des variables d’environnement.

Options de réplication

Patroni utilise la réplication en streaming de Postgres, qui est asynchrone par défaut. La configuration de réplication asynchrone de Patroni permet de définir les paramètres maximum_lag_on_failover. Ce paramètre garantit qu’un basculement ne se produira pas si un suiveur est retardé de plus d’un certain nombre d’octets par rapport au leader. Ce paramètre doit être ajusté en fonction des besoins métiers. Il est également possible d’utiliser la réplication synchrone pour des garanties de durabilité renforcées. Voir la documentation sur les modes de réplication pour plus de détails .

Les applications ne doivent pas utiliser de superutilisateurs

Lors de la connexion depuis une application, utilisez toujours un utilisateur non superutilisateur. Patroni nécessite un accès à la base de données pour fonctionner correctement. En utilisant un superutilisateur depuis une application, vous risquez d’utiliser l’intégralité du pool de connexions, y compris les connexions réservées aux superutilisateurs, avec le paramètre superuser_reserved_connections. Si Patroni ne parvient pas à accéder au primaire car le pool de connexions est plein, le comportement sera indésirable.

Test de votre solution haute disponibilité

Tester une solution haute disponibilité est une opération longue, soumise à de nombreux facteurs. Cela est particulièrement vrai lorsqu’il s’agit d’une application multiplateforme. Un administrateur système expérimenté ou un consultant est nécessaire pour mener à bien cette tâche. Ce point ne peut pas être traité en profondeur dans la documentation.

En revanche, voici quelques composants de votre infrastructure que vous devez impérativement tester :

• Réseau (le réseau devant votre système ainsi que les cartes réseau $$physiques ou virtuelles$$elles-mêmes)
• E/S disque
• Limites de fichiers (nofile sous Linux)
• Mémoire RAM. Même si l’oomkiller est désactivé, l’indisponibilité de la mémoire RAM peut entraîner des problèmes.
• Processeur
• Contestation de virtualisation (surallocation du système hôte)
• Toute limitation cgroup (probablement liée à ce qui précède)
• kill -9 de tout processus postgres (à l’exception du postmaster !). Ceci constitue une simulation raisonnable d’un plantage.

Une chose que vous ne devez pas faire est d’exécuter kill -9 sur un processus postmaster. Cela s’explique par le fait que cela ne reproduit aucun scénario réel. Si vous craignez que votre infrastructure soit compromise et qu’un attaquant puisse exécuter kill -9, aucune configuration de haute disponibilité ne pourra résoudre ce problème. L’attaquant supprimera simplement le processus à nouveau, ou provoquera d’autres perturbations.

2 - Installation

Prérequis pour Mac OS

Pour installer les prérequis sur un Mac, exécutez la commande suivante :

brew install postgresql etcd haproxy libyaml python

Psycopg

À compter de psycopg2-2.8 , la version binaire de psycopg2 ne sera plus installée par défaut. Son installation à partir du code source nécessite un compilateur C ainsi que les paquets de développement postgres+python. Étant donné qu’environnement Python ne permet pas de spécifier la dépendance comme psycopg2 OR psycopg2-binary, vous devrez déterminer vous-même la méthode d’installation.

Plusieurs options sont disponibles :

1. Utilisez le gestionnaire de paquets de votre distribution

sudo apt-get install python3-psycopg2  # install psycopg2 module on Debian/Ubuntu
sudo yum install python3-psycopg2      # install psycopg2 on RedHat/Fedora/CentOS

2. Indiquez psycopg, psycopg2 ou psycopg2-binary dans la liste des dépendances lors de l’installation de Patroni avec pip.

Installation générale de pip

Patroni peut être installé avec pip :

pip install patroni[dependencies]

où dependencies peut être vide ou composé d’un ou plusieurs des éléments suivants :

etcd ou etcd3 module python-etcd afin d’utiliser etcd comme magasin de configuration distribué (DCS)

consul module py-consul afin d’utiliser Consul comme DCS

zookeeper module kazoo afin d’utiliser Zookeeper comme DCS

exhibitor module kazoo afin d’utiliser Exhibitor comme DCS (mêmes dépendances que pour Zookeeper)

kubernetes kubernetes module afin d’utiliser Kubernetes comme DCS dans Patroni

raft module pysyncobj afin d’utiliser l’implémentation Python de Raft comme DCS

aws boto3 afin d’utiliser les rappels AWS

jsonlogger module python-json-logger afin d’activer la journalisation logging au format JSON

systemd systemd-python afin d’utiliser l’intégration sd_notify

tous tous les précédents (à l’exception de la famille psycopg)

psycopg3 module psycopg\[binary\]\>=3.0.0

psycopg2 module psycopg2\>=2.5.4

psycopg2-binary module psycopg2-binary

Par exemple, la commande permettant d’installer Patroni avec psycopg3, les dépendances pour etcd en tant que DCS, et les rappels AWS est :

pip install patroni[psycopg3,etcd3,aws]

Notez que les outils externes appelés lors de la création d’une réplique ou dans des scripts d’amorçage personnalisés (par exemple WAL-E) doivent être installés indépendamment de Patroni.

Installation du paquet sous Linux

Les paquets Patroni peuvent être disponibles pour votre système d’exploitation, produits par la communauté Postgres pour :

• RHEL, Rocky Linux, AlmaLinux ;
• Debian et Ubuntu ;
• SUSE Enterprise Linux.

Vous pouvez également trouver des paquets pour les dépendances directes de Patroni, telles que des modules Python qui pourraient ne pas être disponibles dans les dépôts officiels du système d’exploitation.

Pour plus d’informations, consultez la documentation du dépôt PGDG .

Si vous utilisez un système d’exploitation dérivé de RedHat Enterprise Linux, vous devrez peut-être également installer des paquets provenant du dépôt EPEL repository .

Une fois que vous avez installé le dépôt PGDG pour votre système d’exploitation, vous pouvez installer Patroni.

Installation sur les dérivés de Debian

Avec le dépôt PGDG installé, consultez ci-dessus , puis installez Patroni via apt en exécutant :

apt-get install patroni

Installation sur les dérivés RedHat

Avec le dépôt PGDG installé, voir ci-dessus , installez Patroni avec un DCS etcd via dnf sur RHEL 9 (et dérivés) en exécutant :

dnf install patroni patroni-etcd

Vous pouvez installer etcd à partir de PGDG si votre distribution dérivée de RedHat ne fournit pas de paquets. Sur les nœuds qui hébergeront le DCS, exécutez :

dnf install 'dnf-command(config-manager)'
dnf config-manager --enable pgdg-rhel9-extras
dnf install etcd

Vous pouvez remplacer la version de RHEL par 8 dans le dépôt afin de créer pgdg-rhel8-extras si nécessaire. Le nom du dépôt reste pgdg-rhelN-extras sur RockyLinux, AlmaLinux, Oracle Linux, etc…

Installation sur SUSE Enterprise Linux

Vous devrez peut-être activer les référentiels SUSE PackageHub pour certaines dépendances. Voir la documentation de SUSE PackageHub .

Pour SLES 15 avec le dépôt PGDG installé, consultez ci-dessus pour installer Patroni avec :

zypper install patroni patroni-etcd

Avec le dépôt PackageHub SUSE activé, vous pouvez également installer etcd :

SUSEConnect -p PackageHub/15.5/x86_64
zypper install etcd

Mise à jour

La mise à jour de Patroni est un processus très simple : mettez à jour l’installation logicielle, puis redémarrez le démon Patroni sur chaque nœud du cluster.

Toutefois, redémarrer le démon Patroni entraîne un redémarrage de la base de données PostgreSQL. Dans certaines situations, cela peut provoquer un basculement du nœud primaire de votre cluster ; il est donc recommandé de mettre le cluster en mode maintenance jusqu’à la fin du redémarrage du démon Patroni.

Pour placer le cluster en mode maintenance, exécutez la commande suivante sur l’un des nœuds Patroni :

patronictl pause --wait

Ensuite, sur chaque nœud du cluster, effectuez la mise à jour du paquet nécessaire pour votre système d’exploitation :

apt-get update && apt-get install patroni patroni-etcd

Redémarrez le processus daemon Patroni sur chaque nœud :

systemctl restart patroni

Enfin, reprenez la surveillance de Postgres avec Patroni afin de sortir le serveur du mode maintenance :

patronictl resume --wait

Le cluster sera désormais entièrement opérationnel avec la nouvelle version de Patroni.

3 - Configuration Patroni

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) :

1. charger les paramètres à partir du fichier postgresql.base.conf (ou à partir d’un fichier custom_conf, le cas échéant)
2. charger les paramètres à partir du fichier postgresql.conf
3. charger les paramètres à partir du fichier postgresql.auto.conf
4. 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 :

1. Application des modifications via patronictl_edit_config (ou via l’API REST /config point d’accès)
2. 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.

3.1 - Paramètres de configuration dynamique

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.

3.2 - Paramètres de configuration YAML

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

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

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.

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'

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.

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.3 - Paramètres de configuration de l'environnement

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

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 .

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

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.

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.

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.

4 - API REST Patroni

Patroni dispose d’une API REST riche, utilisée par Patroni lui-même lors de la course au leader, par l’outil patronictl afin d’effectuer des basculements, des basculements planifiés, des réinitialisations, des redémarrages ou des rechargements, par HAProxy ou tout autre équilibreur de charge pour effectuer des vérifications de santé HTTP, et bien entendu également utilisée pour la surveillance. Ci-dessous figure la liste des points d’accès de l’API REST de Patroni.

Points de terminaison de vérification de santé

Pour toutes les requêtes de vérification de santé GET, Patroni renvoie un document JSON indiquant l’état du nœud, accompagné du code d’état HTTP. Si vous ne souhaitez pas ou n’avez pas besoin du document JSON, vous pouvez envisager d’utiliser la méthode HEAD ou OPTIONS au lieu de GET.

• Les requêtes suivantes vers l’API REST de Patroni renvoient le code d’état HTTP 200 uniquement lorsque le nœud Patroni fonctionne en tant que primaire avec verrou de leader :

  • GET /
  • GET /primary
  • GET /read-write

• GET /standby-leader : renvoie le code d’état HTTP 200 uniquement lorsque le nœud Patroni est en cours d’exécution en tant que leader dans un cluster de secours .

• GET /leader : renvoie le code d’état HTTP 200 lorsque le nœud Patroni détient le verrou leader. La différence principale avec les deux précédents points d’accès est qu’elle ne tient pas compte de l’état d’exécution de PostgreSQL en tant que primary ou standby_leader.

• GET /replica : point de terminaison de vérification de santé de la réplique. Il renvoie le code d’état HTTP 200 uniquement lorsque le nœud Patroni est dans l’état running, que son rôle est replica et que l’étiquette noloadbalance n’est pas définie.

• GET /replica?replication_state=<required state> : point de contrôle de réplique. En plus des vérifications effectuées par replica, il vérifie également que l’état de réplication correspond à celui requis. Principalement utile avec replication_state=streaming, afin d’exclure les répliques encore en cours de synchronisation pendant une récupération archivée.

• GET /replica?lag=<max-lag> : point de contrôle de réplique. En plus des vérifications effectuées par replica, il vérifie également le délai de réplication et renvoie le code d’état 200 uniquement lorsque ce délai est inférieur à la valeur spécifiée. La clé cluster.last_leader_operation provenant du DCS est utilisée pour la position WAL du leader et le calcul du délai sur la réplique, pour des raisons de performance. max-lag peut être spécifié en octets (entier) ou sous forme lisible par l’humain, par exemple 16kB, 64MB, 1GB.

  • GET /replica?lag=1048576
  • GET /replica?lag=1024kB
  • GET /replica?lag=10MB
  • GET /replica?lag=1GB

• GET /replica?tag_key1=value1&tag_key2=value2 : point de contrôle de réplique. En outre, il vérifie également les balises définies par l’utilisateur key1 et key2 ainsi que leurs valeurs respectives dans la section tags de la configuration YAML. Si une balise n’est pas définie pour une instance, ou si la valeur dans la configuration YAML ne correspond pas à la valeur demandée, le service renvoie le code d’état HTTP 503.

Dans les requêtes suivantes, comme nous vérifions l’état de leader ou de standby-leader, Patroni ne prend pas en compte les étiquettes définies par l’utilisateur, qui seront ignorées.

• GET /?tag_key1=value1&tag_key2=value2

• GET /leader?tag_key1=value1&tag_key2=value2

• GET /primary?tag_key1=value1&tag_key2=value2

• GET /read-write?tag_key1=value1&tag_key2=value2

• GET /standby_leader?tag_key1=value1&tag_key2=value2

• GET /standby-leader?tag_key1=value1&tag_key2=value2

• GET /read-only : comme le point d’accès précédent, mais inclut également le primaire.

• GET /synchronous ou GET /sync : renvoie le code d’état HTTP 200 uniquement lorsque le nœud Patroni fonctionne en réplica synchrone.

• GET /read-only-sync : comme le point d’accès précédent, mais inclut également le primaire.

• GET /quorum : renvoie le code d’état HTTP 200 uniquement lorsque ce nœud Patroni est répertorié comme nœud de quorum dans synchronous_standby_names sur le primaire.

• GET /read-only-quorum : comme le point d’accès précédent, mais inclut également le primaire.

• GET /asynchronous ou GET /async : renvoie le code d’état HTTP 200 uniquement lorsque le nœud Patroni fonctionne en réplica asynchrone.

• GET /asynchronous?lag=<max-lag> ou GET /async?lag=<max-lag> : point de contrôle de basculement asynchrone. En plus des vérifications provenant de asynchronous ou async, il vérifie également le délai de réplication et renvoie le code d’état 200 uniquement lorsque ce délai est inférieur à la valeur spécifiée. La clé cluster.last_leader_operation provenant du DCS est utilisée pour la position WAL du leader et le calcul du délai sur la réplique, pour des raisons de performance. max-lag peut être spécifié en octets (entier) ou sous forme lisible par l’humain, par exemple 16kB, 64MB, 1GB.

  • GET /async?lag=1048576
  • GET /async?lag=1024kB
  • GET /async?lag=10MB
  • GET /async?lag=1GB

• GET /health : renvoie le code d’état HTTP 200 uniquement lorsque PostgreSQL est en cours d’exécution.

• GET /liveness : renvoie le code d’état HTTP 200 si la boucle de battement de cœur Patroni fonctionne correctement, et 503 si la dernière exécution remonte à plus de ttl secondes sur le serveur primaire ou à plus de 2*ttl secondes sur la réplique. Peut être utilisé pour livenessProbe.

• GET /readiness?lag=<max-lag>&mode=apply|write : renvoie le code d’état HTTP 200 lorsque le nœud Patroni fonctionne en tant que leader ou lorsque PostgreSQL est actif, en réplication et pas trop en retard par rapport au leader. Le paramètre lag définit la marge maximale de retard autorisée pour une instance de secours, avec une valeur par défaut de maximum_lag_on_failover. Le retard peut être spécifié en octets ou en valeurs lisibles par l’humain, par exemple 16kB, 64MB ou 1GB. Le paramètre mode indique si le WAL doit être appliqué (rejoué) ou simplement reçu (écrit). La valeur par défaut est apply.

Lorsqu’il est utilisé comme Kubernetes readinessProbe, il garantit que les nouveaux pods démarrés ne deviennent prêts qu’après avoir rattrapé le leader. Cela, combiné à un PodDisruptionBudget, protège contre une terminaison prématurée du leader lors d’un redémarrage progressif des nœuds. Il garantit également que les répliques incapables de suivre la réplication ne traitent pas le trafic en lecture seule. Ce point d’accès peut être utilisé pour readinessProbe lorsque l’utilisation des endpoints Kubernetes pour les élections de leader n’est pas possible (OpenShift).

Le point d’entrée liveness est très léger et n’exécute aucune requête SQL. Les sondes doivent être configurées de manière à commencer à échouer environ au moment où la clé leader expire. Avec la valeur par défaut de ttl, qui est 30s, les sondes devraient ressembler à l’exemple suivant :

readinessProbe:
  httpGet:
    scheme: HTTP
    path: /readiness
    port: 8008
  initialDelaySeconds: 3
  periodSeconds: 10
  timeoutSeconds: 5
  successThreshold: 1
  failureThreshold: 3
livenessProbe:
  httpGet:
    scheme: HTTP
    path: /liveness
    port: 8008
  initialDelaySeconds: 3
  periodSeconds: 10
  timeoutSeconds: 5
  successThreshold: 1
  failureThreshold: 3

Point de terminaison de surveillance

Le GET /patroni est utilisé par Patroni lors de la course au leader. Il peut également être utilisé par votre système de surveillance. Le document JSON produit par cette extension a la même structure que le JSON produit par les points d’entrée de vérification de santé.

Exemple : un cluster sain

$ curl -s http://localhost:8008/patroni | jq .
{
  "state": "running",
  "postmaster_start_time": "2024-08-28 19:39:26.352526+00:00",
  "role": "primary",
  "server_version": 160004,
  "xlog": {
    "location": 67395656
  },
  "timeline": 1,
  "replication": [
    {
      "usename": "replicator",
      "application_name": "patroni2",
      "client_addr": "10.89.0.6",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    },
    {
      "usename": "replicator",
      "application_name": "patroni3",
      "client_addr": "10.89.0.2",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    }
  ],
  "dcs_last_seen": 1692356718,
  "tags": {
    "clonefrom": true
  },
  "database_system_identifier": "7268616322854375442",
  "patroni": {
    "version": "4.0.0",
    "scope": "demo",
    "name": "patroni1"
  }
}

Exemple : un cluster déverrouillé

$ curl -s http://localhost:8008/patroni  | jq .
{
  "state": "running",
  "postmaster_start_time": "2024-08-28 19:39:26.352526+00:00",
  "role": "replica",
  "server_version": 160004,
  "xlog": {
    "received_location": 67419744,
    "replayed_location": 67419744,
    "replayed_timestamp": null,
    "paused": false
  },
  "timeline": 1,
  "replication": [
    {
      "usename": "replicator",
      "application_name": "patroni2",
      "client_addr": "10.89.0.6",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    },
    {
      "usename": "replicator",
      "application_name": "patroni3",
      "client_addr": "10.89.0.2",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    }
  ],
  "cluster_unlocked": true,
  "dcs_last_seen": 1692356928,
  "tags": {
    "clonefrom": true
  },
  "database_system_identifier": "7268616322854375442",
  "patroni": {
    "version": "4.0.0",
    "scope": "demo",
    "name": "patroni1"
  }
}

Exemple : Un cluster déverrouillé avec le mode de sécurité du DCS activé

$ curl -s http://localhost:8008/patroni  | jq .
{
  "state": "running",
  "postmaster_start_time": "2024-08-28 19:39:26.352526+00:00",
  "role": "replica",
  "server_version": 160004,
  "xlog": {
    "location": 67420024
  },
  "timeline": 1,
  "replication": [
    {
      "usename": "replicator",
      "application_name": "patroni2",
      "client_addr": "10.89.0.6",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    },
    {
      "usename": "replicator",
      "application_name": "patroni3",
      "client_addr": "10.89.0.2",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    }
  ],
  "cluster_unlocked": true,
  "failsafe_mode_is_active": true,
  "dcs_last_seen": 1692356928,
  "tags": {
    "clonefrom": true
  },
  "database_system_identifier": "7268616322854375442",
  "patroni": {
    "version": "4.0.0",
    "scope": "demo",
    "name": "patroni1"
  }
}

Exemple : Un cluster avec le mode pause activé

$ curl -s http://localhost:8008/patroni  | jq .
{
  "state": "running",
  "postmaster_start_time": "2024-08-28 19:39:26.352526+00:00",
  "role": "replica",
  "server_version": 160004,
  "xlog": {
    "location": 67420024
  },
  "timeline": 1,
  "replication": [
    {
      "usename": "replicator",
      "application_name": "patroni2",
      "client_addr": "10.89.0.6",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    },
    {
      "usename": "replicator",
      "application_name": "patroni3",
      "client_addr": "10.89.0.2",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    }
  ],
  "pause": true,
  "dcs_last_seen": 1724874295,
  "tags": {
    "clonefrom": true
  },
  "database_system_identifier": "7268616322854375442",
  "patroni": {
    "version": "4.0.0",
    "scope": "demo",
    "name": "patroni1"
  }
}

Récupérez les métriques Patroni au format Prometheus via l’endpoint GET /metrics.

$ curl http://localhost:8008/metrics

# HELP patroni_version Patroni semver without periods. \
# TYPE patroni_version gauge
patroni_version{scope="batman",name="patroni1"} 040000
# HELP patroni_postgres_running Value is 1 if Postgres is running, 0 otherwise.
# TYPE patroni_postgres_running gauge
patroni_postgres_running{scope="batman",name="patroni1"} 1
# HELP patroni_postmaster_start_time Epoch seconds since Postgres started.
# TYPE patroni_postmaster_start_time gauge
patroni_postmaster_start_time{scope="batman",name="patroni1"} 1724873966.352526
# HELP patroni_primary Value is 1 if this node is the leader, 0 otherwise.
# TYPE patroni_primary gauge
patroni_primary{scope="batman",name="patroni1"} 1
# HELP patroni_xlog_location Current location of the Postgres transaction log, 0 if this node is not the leader.
# TYPE patroni_xlog_location counter
patroni_xlog_location{scope="batman",name="patroni1"} 22320573386952
# HELP patroni_standby_leader Value is 1 if this node is the standby_leader, 0 otherwise.
# TYPE patroni_standby_leader gauge
patroni_standby_leader{scope="batman",name="patroni1"} 0
# HELP patroni_replica Value is 1 if this node is a replica, 0 otherwise.
# TYPE patroni_replica gauge
patroni_replica{scope="batman",name="patroni1"} 0
# HELP patroni_sync_standby Value is 1 if this node is a sync standby replica, 0 otherwise.
# TYPE patroni_sync_standby gauge
patroni_sync_standby{scope="batman",name="patroni1"} 0
# HELP patroni_quorum_standby Value is 1 if this node is a quorum standby replica, 0 otherwise.
# TYPE patroni_quorum_standby gauge
patroni_quorum_standby{scope="batman",name="patroni1"} 0
# HELP patroni_xlog_received_location Current location of the received Postgres transaction log, 0 if this node is not a replica.
# TYPE patroni_xlog_received_location counter
patroni_xlog_received_location{scope="batman",name="patroni1"} 0
# HELP patroni_xlog_replayed_location Current location of the replayed Postgres transaction log, 0 if this node is not a replica.
# TYPE patroni_xlog_replayed_location counter
patroni_xlog_replayed_location{scope="batman",name="patroni1"} 0
# HELP patroni_xlog_replayed_timestamp Current timestamp of the replayed Postgres transaction log, 0 if null.
# TYPE patroni_xlog_replayed_timestamp gauge
patroni_xlog_replayed_timestamp{scope="batman",name="patroni1"} 0
# HELP patroni_xlog_paused Value is 1 if the Postgres xlog is paused, 0 otherwise.
# TYPE patroni_xlog_paused gauge
patroni_xlog_paused{scope="batman",name="patroni1"} 0
# HELP patroni_postgres_streaming Value is 1 if Postgres is streaming, 0 otherwise.
# TYPE patroni_postgres_streaming gauge
patroni_postgres_streaming{scope="batman",name="patroni1"} 1
# HELP patroni_postgres_in_archive_recovery Value is 1 if Postgres is replicating from archive, 0 otherwise.
# TYPE patroni_postgres_in_archive_recovery gauge
patroni_postgres_in_archive_recovery{scope="batman",name="patroni1"} 0
# HELP patroni_postgres_server_version Version of Postgres (if running), 0 otherwise.
# TYPE patroni_postgres_server_version gauge
patroni_postgres_server_version{scope="batman",name="patroni1"} 160004
# HELP patroni_cluster_unlocked Value is 1 if the cluster is unlocked, 0 if locked.
# TYPE patroni_cluster_unlocked gauge
patroni_cluster_unlocked{scope="batman",name="patroni1"} 0
# HELP patroni_failsafe_mode_is_active Value is 1 if failsafe mode is active, 0 otherwise.
# TYPE patroni_failsafe_mode_is_active gauge
patroni_failsafe_mode_is_active{scope="batman",name="patroni1"} 0
# HELP patroni_failsafe_mode_enabled Value is 1 if failsafe_mode is enabled, 0 otherwise.
# TYPE patroni_failsafe_mode_enabled gauge
patroni_failsafe_mode_enabled{scope="batman",name="patroni1"} 0
# HELP patroni_failsafe_member Value is 1 if this node is a member of failsafe, 0 otherwise.
# TYPE patroni_failsafe_member gauge
patroni_failsafe_member{scope="batman",name="patroni1"} 0
# HELP patroni_postgres_timeline Postgres timeline of this node (if running), 0 otherwise.
# TYPE patroni_postgres_timeline gauge
patroni_postgres_timeline{scope="batman",name="patroni1"} 24
# HELP patroni_dcs_last_seen Epoch timestamp when DCS was last contacted successfully by Patroni.
# TYPE patroni_dcs_last_seen gauge
patroni_dcs_last_seen{scope="batman",name="patroni1"} 1724874235
# HELP patroni_pending_restart Value is 1 if the node needs a restart, 0 otherwise.
# TYPE patroni_pending_restart gauge
patroni_pending_restart{scope="batman",name="patroni1"} 1
# HELP patroni_is_paused Value is 1 if auto failover is disabled, 0 otherwise.
# TYPE patroni_is_paused gauge
patroni_is_paused{scope="batman",name="patroni1"} 1
# HELP patroni_postgres_state Numeric representation of Postgres state.
# Values: 0=initdb, 1=initdb_failed, 2=custom_bootstrap, 3=custom_bootstrap_failed, 4=creating_replica, 5=running, 6=starting, 7=bootstrap_starting, 8=start_failed, 9=restarting, 10=restart_failed, 11=stopping, 12=stopped, 13=stop_failed, 14=crashed
# TYPE patroni_postgres_state gauge
patroni_postgres_state{scope="batman",name="patroni1"} 5
# HELP patroni_failover_priority Failover priority of this node.
# TYPE patroni_failover_priority gauge
patroni_failover_priority{scope="batman",name="patroni1"} 1

Valeurs d’état PostgreSQL

La métrique patroni_postgres_state fournit une représentation numérique de l’état actuel de l’instance PostgreSQL. Cela est utile pour les systèmes de surveillance et d’alerte qui doivent suivre les changements d’état au fil du temps. Les valeurs numériques sont générées à l’aide de la méthode statique PostgresqlState.get_metrics_description().

Valeurs d’état de PostgreSQL

Points de terminaison d’état du cluster

• L’endpoint GET /cluster génère un document JSON décrivant la topologie et l’état actuels du cluster :

$ curl -s http://localhost:8008/cluster | jq .
{
  "members": [
    {
      "name": "patroni1",
      "role": "leader",
      "state": "running",
      "api_url": "http://10.89.0.4:8008/patroni",
      "host": "10.89.0.4",
      "port": 5432,
      "timeline": 5,
      "tags": {
        "clonefrom": true
      }
    },
    {
      "name": "patroni2",
      "role": "replica",
      "state": "streaming",
      "api_url": "http://10.89.0.6:8008/patroni",
      "host": "10.89.0.6",
      "port": 5433,
      "timeline": 5,
      "tags": {
        "clonefrom": true
      },
      "receive_lag": 0,
      "receive_lsn": "0/4000060",
      "replay_lag": 0,
      "replay_lsn": "0/4000060",
      "lag": 0,
      "lsn": "0/4000060"
    }
  ],
  "scope": "demo",
  "scheduled_switchover": {
    "at": "2023-09-24T10:36:00+02:00",
    "from": "patroni1",
    "to": "patroni3"
  }
}

• Le point d’accès GET /history fournit une vue sur l’historique des basculements ou des basculements planifiés du cluster. Le format est très similaire au contenu des fichiers d’historique dans le répertoire pg_wal. La seule différence réside dans le champ horodatage, qui indique quand la nouvelle ligne temporelle a été créée.

$ curl -s http://localhost:8008/history | jq .
[
  [
    1,
    25623960,
    "no recovery target specified",
    "2019-09-23T16:57:57+02:00"
  ],
  [
    2,
    25624344,
    "no recovery target specified",
    "2019-09-24T09:22:33+02:00"
  ],
  [
    3,
    25624752,
    "no recovery target specified",
    "2019-09-24T09:26:15+02:00"
  ],
  [
    4,
    50331856,
    "no recovery target specified",
    "2019-09-24T09:35:52+02:00"
  ]
]

Point d’entrée de configuration

GET /config : Obtenir la version actuelle de la configuration dynamique :

$ curl -s http://localhost:8008/config | jq .
{
  "ttl": 30,
  "loop_wait": 10,
  "retry_timeout": 10,
  "maximum_lag_on_failover": 1048576,
  "postgresql": {
    "use_slots": true,
    "use_pg_rewind": true,
    "parameters": {
      "hot_standby": "on",
      "wal_level": "hot_standby",
      "max_wal_senders": 5,
      "max_replication_slots": 5,
      "max_connections": "100"
    }
  }
}

PATCH /config : Modifiez la configuration existante.

$ curl -s -XPATCH -d \
    '{"loop_wait":5,"ttl":20,"postgresql":{"parameters":{"max_connections":"101"}}}' \
    http://localhost:8008/config | jq .
{
  "ttl": 20,
  "loop_wait": 5,
  "maximum_lag_on_failover": 1048576,
  "retry_timeout": 10,
  "postgresql": {
    "use_slots": true,
    "use_pg_rewind": true,
    "parameters": {
      "hot_standby": "on",
      "wal_level": "hot_standby",
      "max_wal_senders": 5,
      "max_replication_slots": 5,
      "max_connections": "101"
    }
  }
}

L’appel d’API REST ci-dessus met à jour la configuration existante et renvoie la configuration mise à jour.

Vérifions que le nœud a bien appliqué cette configuration. Tout d’abord, il doit commencer à imprimer des lignes de journalisation toutes les 5 secondes (loop_wait=5). Le changement de “max_connections” nécessite un redémarrage, donc le drapeau “pending_restart” doit être exposé :

$ curl -s http://localhost:8008/patroni | jq .
{
  "database_system_identifier": "6287881213849985952",
  "postmaster_start_time": "2024-08-28 19:39:26.352526+00:00",
  "xlog": {
    "location": 2197818976
  },
  "timeline": 1,
  "dcs_last_seen": 1724874545,
  "database_system_identifier": "7408277255830290455",
  "pending_restart": true,
  "pending_restart_reason": {
    "max_connections": {
      "old_value": "100",
      "new_value": "101"
    }
  },
  "patroni": {
    "version": "4.0.0",
    "scope": "batman",
    "name": "patroni1"
  },
  "state": "running",
  "role": "primary",
  "server_version": 160004
}

Suppression des paramètres :

Si vous souhaitez supprimer (réinitialiser) un paramètre, appliquez une mise à jour avec null :

$ curl -s -XPATCH -d \
    '{"postgresql":{"parameters":{"max_connections":null}}}' \
    http://localhost:8008/config | jq .
{
  "ttl": 20,
  "loop_wait": 5,
  "retry_timeout": 10,
  "maximum_lag_on_failover": 1048576,
  "postgresql": {
    "use_slots": true,
    "use_pg_rewind": true,
    "parameters": {
      "hot_standby": "on",
      "unix_socket_directories": ".",
      "wal_level": "hot_standby",
      "max_wal_senders": 5,
      "max_replication_slots": 5
    }
  }
}

L’appel ci-dessus retire postgresql.parameters.max_connections de la configuration dynamique.

PUT /config : Il est également possible d’effectuer la réécriture complète d’une configuration dynamique existante sans condition :

$ curl -s -XPUT -d \
    '{"maximum_lag_on_failover":1048576,"retry_timeout":10,"postgresql":{"use_slots":true,"use_pg_rewind":true,"parameters":{"hot_standby":"on","wal_level":"hot_standby","unix_socket_directories":".","max_wal_senders":5}},"loop_wait":3,"ttl":20}' \
    http://localhost:8008/config | jq .
{
  "ttl": 20,
  "maximum_lag_on_failover": 1048576,
  "retry_timeout": 10,
  "postgresql": {
    "use_slots": true,
    "parameters": {
      "hot_standby": "on",
      "unix_socket_directories": ".",
      "wal_level": "hot_standby",
      "max_wal_senders": 5
    },
    "use_pg_rewind": true
  },
  "loop_wait": 3
}

Points de terminaison de basculement planifié et de basculement

basculement planifié

Le point de terminaison /switchover ne fonctionne que lorsque le cluster est sain (un leader est présent). Il permet également de planifier un basculement planifié à une heure donnée.

Lors de l’appel de l’endpoint /switchover, un candidat peut être spécifié mais n’est pas obligatoire, contrairement à l’endpoint /failover. Si aucun candidat n’est fourni, tous les nœuds du cluster éligibles participeront à la course au leader après le départ du leader.

Dans le corps JSON de la requête POST, vous devez spécifier le champ leader. Les champs candidate et scheduled_at sont facultatifs et peuvent être utilisés pour planifier un basculement à une heure précise.

Selon la situation, les requêtes peuvent renvoyer des codes d’état HTTP et des corps différents. Le code d’état 200 est retourné lorsque le basculement planifié ou le basculement s’est terminé avec succès. Si le basculement planifié a été correctement planifié, Patroni renvoie le code d’état HTTP 202. En cas d’erreur, un code d’état d’erreur (l’un des codes 400, 412 ou 503) est retourné, accompagné de détails dans le corps de la réponse.

DELETE /switchover peut être utilisé pour supprimer le basculement planifié actuellement prévu.

Exemple : effectuer un basculement planifié vers une station de secours saine

$ curl -s http://localhost:8008/switchover -XPOST -d '{"leader":"postgresql1"}'
Successfully switched over to "postgresql2"

Exemple : effectuer un basculement planifié vers un nœud spécifique

$ curl -s http://localhost:8008/switchover -XPOST -d \
    '{"leader":"postgresql1","candidate":"postgresql2"}'
Successfully switched over to "postgresql2"

Exemple : planifier un basculement planifié du leader vers un autre nœud de secours sain du cluster à une heure précise.

$ curl -s http://localhost:8008/switchover -XPOST -d \
    '{"leader":"postgresql0","scheduled_at":"2019-09-24T12:00+00"}'
Switchover scheduled

basculement

Le point de terminaison /failover peut être utilisé pour effectuer un basculement manuel lorsque aucun nœud sain n’est disponible (par exemple, vers un réplica asynchrone si tous les réplicas synchrones ne sont pas suffisamment sains pour être promus). Toutefois, il n’existe aucune obligation pour un cluster de ne pas avoir de leader : le basculement peut également être exécuté sur un cluster sain.

Dans le corps JSON de la requête POST, vous devez spécifier le champ candidate. Si le champ leader est spécifié, un basculement planifié est déclenché à la place.

Exemple :

$ curl -s http://localhost:8008/failover -XPOST -d '{"candidate":"postgresql1"}'
Successfully failed over to "postgresql1"

[!AVERTISSEMENT]

Faites preuve de prudence lors de l’utilisation de cette API, car cela peut entraîner une perte de données dans certaines situations. Dans la plupart des cas, l’endpoint de basculement planifié répond aux besoins de l’administrateur.

Les points de terminaison POST /switchover et POST /failover sont utilisés par patronictl_switchover et patronictl_failover respectivement.

DELETE /switchover est utilisé par patronictl flush cluster-name basculement planifié .

Comparaison entre basculement et basculement planifié

Standby sain

Plusieurs vérifications doivent être effectuées par un membre d’un cluster afin de pouvoir participer à la course au rôle de leader lors d’un basculement planifié ou de devenir leader en tant que candidat au basculement ou au basculement planifié :

• • être accessible via l’API Patroni ;
• • ne pas avoir l’étiquette nofailover définie sur true ;
• • avoir le watchdog entièrement fonctionnel (si requis par la configuration) ;
• • en cas de basculement planifié dans un cluster sain ou de basculement automatique, ne pas dépasser le décalage maximal de réplication (maximum_lag_on_failover paramètre de configuration ) ;
• • en cas de basculement planifié dans un cluster sain ou de basculement automatique, ne pas avoir un numéro de timeline inférieur à celui du cluster si check_timeline paramètre de configuration est défini sur true ;
• • en mode synchrone :
  • • En cas de basculement planifié (avec ou sans candidat) : être inclus dans la liste des membres /sync ;
  • • En cas de basculement dans des clusters sains ou défaillants, cette vérification est omise.

[!AVERTISSEMENT]

En cas de basculement manuel dans un cluster sans leader, un candidat peut être promu même si : - il n’est pas membre du /sync lorsque le mode synchrone est activé ; - son retard dépasse le retard maximal de réplication autorisé ; - son numéro de timeline est inférieur au dernier numéro de timeline connu du cluster.

Point d’arrêt de redémarrage

• POST /restart : Vous pouvez redémarrer Postgres sur le nœud spécifique en effectuant l’appel POST /restart. Dans le corps JSON de la requête POST, il est possible de spécifier de manière optionnelle certaines conditions de redémarrage :
  • restart_pending : booléen, si défini à true, Patroni redémarrera PostgreSQL uniquement lorsque le redémarrage est en attente afin d’appliquer certaines modifications de configuration de PostgreSQL.
  • role : effectuer le redémarrage uniquement si le rôle actuel du nœud correspond au rôle fourni dans la requête POST.
  • postgres_version : effectuer le redémarrage uniquement si la version actuelle de PostgreSQL est inférieure à celle spécifiée dans la requête POST.
  • timeout : durée d’attente avant que PostgreSQL ne commence à accepter les connexions. Remplace primary_start_timeout.
  • schedule : horodatage avec fuseau horaire, planifier le redémarrage à une date future.
• DELETE /restart : supprimer le redémarrage planifié

Les points de terminaison POST /restart et DELETE /restart sont utilisés par patronictl_restart et patronictl flush cluster-name restart respectivement.

Point de terminaison de rechargement

L’appel POST /reload ordonne à Patroni de relire et d’appliquer le fichier de configuration. Cela équivaut à envoyer le signal SIGHUP au processus Patroni. Si vous avez modifié certains paramètres de Postgres nécessitant un redémarrage (comme shared_buffers), vous devez toujours effectuer explicitement le redémarrage de Postgres en appelant l’endpoint POST /restart ou à l’aide de patronictl restart .

Le point de terminaison reload est utilisé par patronictl_reload .

Réinitialiser le point de terminaison

POST /reinitialize : réinitialiser le répertoire de données PostgreSQL sur le nœud spécifié. Cette opération ne peut être exécutée qu’aux répliques. Une fois appelée, elle supprime le répertoire de données et déclenche pg_basebackup ou une autre méthode alternative de création de réplique replica creation method .

L’appel peut échouer si Patroni est en boucle de récupération (redémarrage) d’une instance Postgres défaillante. Pour contourner ce problème, il est possible de spécifier {"force":true} dans le corps de la requête.

Vous pouvez spécifier {“from-leader”:true} dans le corps de la requête pour obtenir directement un basebackup depuis le nœud leader. Cela est utile lors de l’exécution d’un reinit lorsque tous les nœuds répliques échouent.

Le point de terminaison de réinitialisation est utilisé par patronictl_reinit .

5 - patronictl

Patroni dispose d’une interface en ligne de commande nommée patronictl , utilisée principalement pour interagir avec l’API REST de Patroni et avec le DCS. Elle vise à simplifier l’exécution d’opérations au sein du cluster et peut être facilement utilisée par des humains ou des scripts.

Configuration

patronictl utilise trois sections de la configuration :

• ctl : comment s’authentifier contre l’API REST de Patroni, et comment valider l’identité du serveur. Consulter paramètres ctl pour plus de détails ;
• restapi : comment s’authentifier contre l’API REST de Patroni, et comment valider l’identité du serveur. N’est utilisé que si la configuration ctl est insuffisante. patronictl s’intéresse principalement à la section restapi.authentication (en cas de non-présence de ctl.authentication) et au paramètre restapi.cafile (en cas de non-présence de ctl.cacert). Consulter paramètres de l’API REST pour plus de détails ;
• DCS (par exemple etcd) : comment contacter et s’authentifier contre le DCS utilisé par Patroni.

Ces options de configuration peuvent provenir soit de variables d’environnement, soit d’un fichier de configuration. Consultez les sections ci-dessus dans Paramètres de configuration par environnement ou Paramètres de configuration YAML pour comprendre comment définir ces options via des variables d’environnement ou un fichier de configuration.

Si vous choisissez d’utiliser des variables d’environnement, il s’agit d’une approche directe. Patronictl lira les variables d’environnement et utilisera leurs valeurs.

Si vous choisissez d’utiliser un fichier de configuration, vous disposez de différentes méthodes pour indiquer à patronictl le fichier à utiliser. Par défaut, patronictl tentera de charger un fichier de configuration nommé patronictl.yaml, qui doit se trouver dans l’un des chemins suivants, selon votre système :

• macOS : ~/Library/Application Support/patroni
• macOS (POSIX) : ~/.patroni
• Unix : ~/.config/patroni
• Unix (POSIX) : ~/.patroni
• Windows (enregistrement local) : C:\Users\<user>\AppData\Roaming\patroni
• Windows (sans enregistrement local) : C:\Users\<user>\AppData\Local\patroni

Vous pouvez remplacer ce comportement soit en :

• Définition de la variable d’environnement PATRONICTL_CONFIG_FILE avec le chemin vers un fichier de configuration personnalisé ;
• Utilisation de l’argument en ligne de commande -c / --config-file de patronictl avec le chemin vers un fichier de configuration personnalisé.

Utilisation

patronictl met à disposition plusieurs opérations pratiques. Cette section a pour but de décrire chacune d’entre elles.

Avant d’aborder chacune des sous-commandes de patronictl , sachez que patronictl dispose elle-même des arguments suivants en ligne de commande :

-c / --config-file Comme expliqué précédemment, utilisé pour spécifier le chemin vers un fichier de configuration pour patronictl .

-d / --dcs-url / --dcs Fournir une chaîne de connexion vers le DCS utilisé par Patroni.

Cet argument peut être utilisé soit pour remplacer les paramètres DCS et namespace provenant de la configuration patronictl , soit pour les définir s’ils sont absents de la configuration.

La valeur doit être au format DCS://HOST:PORT/NAMESPACE, par exemple etcd3://localhost:2379/service pour se connecter à etcd v3 en cours d’exécution sur localhost avec le cluster Patroni stocké dans l’espace de noms service. Toute partie manquante dans la valeur de l’argument sera remplacée par la valeur présente dans la configuration ou par sa valeur par défaut.

-k / --insecure Indicateur permettant de contourner la validation du certificat SSL du serveur API REST.

Voici le synopsis de l’exécution d’une commande depuis le patronictl :

patronictl [ { -c | --config-file } CONFIG_FILE ]
  [ { -d | --dcs-url | --dcs } DCS_URL ] 
  [ { -k | --insecure } ]
  SUBCOMMAND

Dans les sous-sections suivantes, vous trouverez la description de chaque commande implémentée par patronictl . Pour illustrer, nous utiliserons les fichiers de configuration présents dans le dépôt GitHub de Patroni (fichiers postgres0.yml, postgres1.yml et postgres2.yml).

patronictl demote-cluster

Synopsis

demote-cluster
  [ CLUSTER_NAME ]
  [ --host HOST ]
  [ --port PORT ]
  [ --restore-command RESTORE_COMMAND ]
  [ --primary-slot-name PRIMARY_SLOT_NAME ]
  [ --force ]

Description

patronictl demote-cluster convertit un cluster Patroni régulier en cluster de secours standby cluster .

La commande applique une mise à jour de la configuration dynamique avec une section standby_cluster construite à partir des options de connexion fournies pour le primaire distant, puis attend que le leader soit en cours d’exécution en tant que leader de basculement. Elle affiche la topologie actuelle du cluster avant de modifier la configuration et demande une confirmation, sauf si --force est utilisé.

Au moins un des éléments --host, --port ou --restore-command doit être spécifié.

Paramètres

CLUSTER_NAME : Nom du cluster Patroni.

Si elle n’est pas fournie, patronictl tentera de la récupérer à partir de la configuration scope, si elle existe.

--host : Adresse du nœud distant.

--port : Port du nœud distant.

--restore-command : Commande permettant de restaurer les enregistrements WAL depuis le serveur primaire distant.

--primary-slot-name : Nom de l’ensemble de réplication sur le nœud distant à utiliser pour la réplication.

--force : Indicateur permettant de passer outre les invites de confirmation lors de la désactivation du cluster.

Utile pour les scripts.

Exemples

Baissez le cluster en cluster de secours qui suit un point de terminaison primaire distant :

$ patronictl -c postgres0.yml demote-cluster batman --host 192.0.2.10 --port 5432 --primary-slot-name batman --force

patronictl dsn

Synopsis

dsn
  [ CLUSTER_NAME ]
  [ { { -r | --role } { leader | primary | standby-leader | replica | standby | any } | { -m | --member } MEMBER_NAME } ]
  [ --group CITUS_GROUP ]

Description

patronictl dsn obtient la chaîne de connexion d’un membre du cluster Patroni.

Si plusieurs membres correspondent aux paramètres de cette commande, l’un d’entre eux sera sélectionné, en priorisant le nœud primaire.

Paramètres

CLUSTER_NAME : Nom du cluster Patroni.

Si elle n’est pas fournie, patronictl tentera de la récupérer à partir de la configuration scope, si elle existe.

-r / --role Choisissez un membre ayant le rôle indiqué.

Le rôle peut être l’un des suivants :

• leader : le leader d’un cluster Patroni régulier ou d’un cluster Patroni en veille ; ou
• primary : le leader d’un cluster Patroni régulier ; ou
• standby-leader : le leader d’un cluster Patroni en veille ; ou
• replica : une réplique d’un cluster Patroni ; ou
• standby : identique à replica ; ou
• any : tout rôle. Identique à la suppression de ce paramètre ; ou

-m / --member Sélectionnez un membre du cluster portant le nom indiqué.

MEMBER_NAME est le nom du membre.

--group Sélectionnez un membre faisant partie du groupe Citus indiqué.

CITUS_GROUP est l’identifiant du groupe Citus.

Exemples

Obtenir le DSN du nœud primaire :

$ patronictl -c postgres0.yml dsn batman -r primary
host=127.0.0.1 port=5432

Obtenir la chaîne de connexion (DSN) du nœud nommé postgresql1 :

$ patronictl -c postgres0.yml dsn batman --member postgresql1
host=127.0.0.1 port=5433

patronictl edit-config

Synopsis

edit-config
  [ CLUSTER_NAME ]
  [ --group CITUS_GROUP ]
  [ { -q | --quiet } ]
  [ { -s | --set } CONFIG="VALUE" [, ... ] ]
  [ { -p | --pg } PG_CONFIG="PG_VALUE" [, ... ] ]
  [ { --apply | --replace } CONFIG_FILE ]
  [ --force ]

Description

patronictl edit-config modifie la configuration dynamique du cluster et met à jour le DCS avec ces modifications.

Paramètres

CLUSTER_NAME : Nom du cluster Patroni.

Si elle n’est pas fournie, patronictl tentera de la récupérer à partir de la configuration scope, si elle existe.

--group Modifie la configuration dynamique du groupe Citus indiqué.

Si elle n’est pas fournie, patronictl tentera de la récupérer à partir de la configuration citus.group, si elle existe.

CITUS_GROUP est l’identifiant du groupe Citus.

-q / --quiet Indicateur permettant de passer outre l’affichage de la différence de configuration.

-s / --set Définir une option de configuration dynamique donnée avec une valeur donnée.

CONFIG est le nom du chemin de configuration dynamique dans l’arborescence YAML, dont les niveaux sont séparés par ..

VALUE est la valeur de CONFIG. Si elle est égale à null, alors CONFIG sera supprimé de la configuration dynamique.

-p / --pg Définir une option de configuration dynamique Postgres donnée avec la valeur indiquée.

Il s’agit essentiellement d’un raccourci pour --s / --set avec CONFIG préfixé par postgresql.parameters..

PG_CONFIG est le nom de la configuration Postgres à définir.

PG_VALUE est la valeur de PG_CONFIG. Si elle est égale à null, alors PG_CONFIG sera supprimé de la configuration dynamique.

--apply Appliquer la configuration dynamique à partir du fichier spécifié.

Il est similaire à la spécification de plusieurs options -s / --set, une pour chaque configuration de CONFIG_FILE.

CONFIG_FILE est le chemin vers un fichier contenant la configuration dynamique à appliquer, au format YAML. Utilisez - si vous souhaitez lire à partir de stdin.

--replace Remplacez la configuration dynamique dans le DCS par la configuration dynamique spécifiée dans le fichier fourni.

CONFIG_FILE est le chemin vers un fichier contenant la nouvelle configuration dynamique à appliquer, au format YAML. Utilisez - si vous souhaitez lire depuis stdin.

--force Indicateur permettant de passer outre les invites de confirmation lors du changement de la configuration dynamique.

Utile pour les scripts.

Exemples

Modifiez le paramètre GUC Postgres max_connections :

patronictl -c postgres0.yml edit-config batman --pg max_connections="150" --force
---
+++
@@ -1,6 +1,8 @@
loop_wait: 10
maximum_lag_on_failover: 1048576
postgresql:
+  parameters:
+    max_connections: 150
  pg_hba:
  - host replication replicator 127.0.0.1/32 md5
  - host all all 0.0.0.0/0 md5

Configuration changed

Modifiez les paramètres loop_wait et ttl :

patronictl -c postgres0.yml edit-config batman --set loop_wait="15" --set ttl="45" --force
---
+++
@@ -1,4 +1,4 @@
-loop_wait: 10
+loop_wait: 15
maximum_lag_on_failover: 1048576
postgresql:
  pg_hba:
@@ -6,4 +6,4 @@
  - host all all 0.0.0.0/0 md5
  use_pg_rewind: true
retry_timeout: 10
-ttl: 30
+ttl: 45

Configuration changed

Supprimez le paramètre maximum_lag_on_failover de la configuration dynamique :

patronictl -c postgres0.yml edit-config batman --set maximum_lag_on_failover="null" --force
---
+++
@@ -1,5 +1,4 @@
loop_wait: 10
-maximum_lag_on_failover: 1048576
postgresql:
  pg_hba:
  - host replication replicator 127.0.0.1/32 md5

Configuration changed

patronictl basculement

Synopsis

failover
  [ CLUSTER_NAME ]
  [ --group CITUS_GROUP ]
  --candidate CANDIDATE_NAME
  [ --force ]

Description

patronictl failover effectue un basculement manuel dans le cluster.

Il est conçu pour être utilisé lorsque le cluster n’est pas sain, par exemple :

• Il n’y a pas de leader ; ou
• Aucun standby synchrone n’est disponible dans un cluster synchrone.

Il permet également de basculer vers un nœud asynchrone si le mode synchrone est activé.

[!AVERTISSEMENT]

Le déclenchement d’un basculement peut entraîner une perte de données, selon l’état de mise à jour de la réplique promue par rapport au primaire.

Paramètres

CLUSTER_NAME : Nom du cluster Patroni.

Si elle n’est pas fournie, patronictl tentera de la récupérer à partir de la configuration scope, si elle existe.

--group Effectuez un basculement dans le groupe Citus indiqué.

CITUS_GROUP est l’identifiant du groupe Citus.

--candidate Nœud à promouvoir lors d’un basculement.

CANDIDATE_NAME est le nom du nœud à promouvoir.

--force Indicateur permettant de passer outre les invites de confirmation lors d’un basculement.

Utile pour les scripts.

Exemples

Basculer vers le nœud postgresql2 :

$ patronictl -c postgres0.yml failover batman --candidate postgresql2 --force
Current cluster topology
+ Cluster: batman (7277694203142172922) -+-----------+----+-------------+-----+------------+-----+
| Member      | Host           | Role    | State     | TL | Receive LSN | Lag | Replay LSN | Lag |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+
| postgresql0 | 127.0.0.1:5432 | Leader  | running   |  3 |             |     |            |     |
| postgresql1 | 127.0.0.1:5433 | Replica | streaming |  3 |   0/40004E8 |   0 |  0/40004E8 |   0 |
| postgresql2 | 127.0.0.1:5434 | Replica | streaming |  3 |   0/40004E8 |   0 |  0/40004E8 |   0 |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+
2023-09-12 11:52:27.50978 Successfully failed over to "postgresql2"
+ Cluster: batman (7277694203142172922) -+---------+----+-------------+---------+------------+---------+
| Member      | Host           | Role    | State   | TL | Receive LSN |     Lag | Replay LSN |     Lag |
+-------------+----------------+---------+---------+----+-------------+---------+------------+---------+
| postgresql0 | 127.0.0.1:5432 | Replica | stopped |    |     unknown | unknown |    unknown | unknown |
| postgresql1 | 127.0.0.1:5433 | Replica | running |  3 |   0/4000188 |       0 |  0/4000188 |       0 |
| postgresql2 | 127.0.0.1:5434 | Leader  | running |  3 |             |         |            |         |
+-------------+----------------+---------+---------+----+-------------+---------+------------+---------+

patronictl flush

Synopsis

flush
  CLUSTER_NAME
  [ MEMBER_NAME [, ... ] ]
  { restart | switchover }
  [ --group CITUS_GROUP ]
  [ { -r | --role } { leader | primary | standby-leader | replica | standby | any } ]
  [ --force ]

Description

patronictl flush rejette les événements planifiés, le cas échéant.

Paramètres

CLUSTER_NAME Nom du cluster Patroni.

MEMBER_NAME Ignorer les événements planifiés pour le ou les membres Patroni indiqués.

Plusieurs membres peuvent être spécifiés. Si aucun membre n’est spécifié, tous les membres sont pris en compte.

restart Ignorer les événements de redémarrage planifiés.

switchover Annuler l’événement de basculement planifié.

--group Ignore les événements planifiés du groupe Citus indiqué.

CITUS_GROUP est l’identifiant du groupe Citus.

-r / --role Ignorer les événements planifiés pour les membres ayant le rôle spécifié.

Le rôle peut être l’un des suivants :

• leader : le leader d’un cluster Patroni régulier ou d’un cluster Patroni en veille ; ou
• primary : le leader d’un cluster Patroni régulier ; ou
• standby-leader : le leader d’un cluster Patroni en veille ; ou
• replica : une réplique d’un cluster Patroni ; ou
• standby : identique à replica ; ou
• any : tout rôle. Identique à omettre ce paramètre.

--force Indicateur permettant de passer outre les invites de confirmation lors de l’exécution de l’opération d’effacement.

Utile pour les scripts.

Exemples

Annuler un événement de basculement planifié :

$ patronictl -c postgres0.yml flush batman switchover --force
Success: scheduled switchover deleted

Annuler le redémarrage planifié de tous les nœuds de secours :

$ patronictl -c postgres0.yml flush batman restart -r replica --force
+ Cluster: batman (7277694203142172922) -+-----------+----+-------------+-----+------------+-----+---------------------------+
| Member      | Host           | Role    | State     | TL | Receive LSN | Lag | Replay LSN | Lag | Scheduled restart         |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+---------------------------+
| postgresql0 | 127.0.0.1:5432 | Leader  | running   |  5 |             |     |            |     | 2025-03-23T18:00:00-03:00 |
| postgresql1 | 127.0.0.1:5433 | Replica | streaming |  5 |   0/4000400 |   0 |  0/4000400 |   0 | 2025-03-23T18:00:00-03:00 |
| postgresql2 | 127.0.0.1:5434 | Replica | streaming |  5 |   0/4000400 |   0 |  0/4000400 |   0 | 2025-03-23T18:00:00-03:00 |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+---------------------------+
Success: flush scheduled restart for member postgresql1
Success: flush scheduled restart for member postgresql2

Annuler le redémarrage planifié des nœuds postgresql0 et postgresql1 :

$ patronictl -c postgres0.yml flush batman postgresql0 postgresql1 restart --force
+ Cluster: batman (7277694203142172922) -+-----------+----+-------------+-----+------------+-----+---------------------------+
| Member      | Host           | Role    | State     | TL | Receive LSN | Lag | Replay LSN | Lag | Scheduled restart         |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+---------------------------+
| postgresql0 | 127.0.0.1:5432 | Leader  | running   |  5 |             |     |            |     | 2025-03-23T18:00:00-03:00 |
| postgresql1 | 127.0.0.1:5433 | Replica | streaming |  5 |   0/4000400 |   0 |  0/4000400 |   0 | 2025-03-23T18:00:00-03:00 |
| postgresql2 | 127.0.0.1:5434 | Replica | streaming |  5 |   0/4000400 |   0 |  0/4000400 |   0 | 2025-03-23T18:00:00-03:00 |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+---------------------------+
Success: flush scheduled restart for member postgresql0
Success: flush scheduled restart for member postgresql1

patronictl history

Synopsis

history
  [ CLUSTER_NAME ]
  [ --group CITUS_GROUP ]
  [ { -f | --format } { pretty | tsv | json | yaml } ]

Description

patronictl history affiche l’historique des événements de basculement et de basculement planifié du cluster, le cas échéant.

Les informations suivantes sont incluses dans la sortie :

TL Timeline Postgres au moment de l’événement.

LSN LSN de Postgres au moment de l’événement.

Reason Raison extraite du fichier Postgres .history.

Timestamp Heure à laquelle l’événement s’est produit.

New Leader Membre Patroni ayant été promu pendant l’événement.

Paramètres

CLUSTER_NAME Nom du cluster Patroni.

Si elle n’est pas fournie, patronictl tentera de la récupérer à partir de la configuration scope, si elle existe.

--group Affiche l’historique des événements du groupe Citus spécifié.

CITUS_GROUP est l’identifiant du groupe Citus.

Si elle n’est pas fournie, patronictl tentera de la récupérer à partir de la configuration citus.group, si elle existe.

-f / --format Comment formater la liste des événements dans la sortie.

Le format peut être l’un des suivants :

• pretty : affiche l’historique sous forme de tableau élégant ; ou
• tsv : affiche l’historique sous forme d’information tabulaire, les colonnes étant séparées par \t ; ou
• json : affiche l’historique au format JSON ; ou
• yaml : affiche l’historique au format YAML.

La valeur par défaut est pretty.

--force Indicateur permettant de passer outre les invites de confirmation lors de l’exécution de l’opération d’effacement.

Utile pour les scripts.

Exemples

Affichez l’historique des événements :

$ patronictl -c postgres0.yml history batman
+----+----------+------------------------------+----------------------------------+-------------+
| TL |      LSN | Reason                       | Timestamp                        | New Leader  |
+----+----------+------------------------------+----------------------------------+-------------+
|  1 | 24392648 | no recovery target specified | 2023-09-11T22:11:27.125527+00:00 | postgresql0 |
|  2 | 50331864 | no recovery target specified | 2023-09-12T11:34:03.148097+00:00 | postgresql0 |
|  3 | 83886704 | no recovery target specified | 2023-09-12T11:52:26.948134+00:00 | postgresql2 |
|  4 | 83887280 | no recovery target specified | 2023-09-12T11:53:09.620136+00:00 | postgresql0 |
+----+----------+------------------------------+----------------------------------+-------------+

Affichez l’historique des événements au format YAML :

$ patronictl -c postgres0.yml history batman -f yaml
- LSN: 24392648
  New Leader: postgresql0
  Reason: no recovery target specified
  TL: 1
  Timestamp: '2023-09-11T22:11:27.125527+00:00'
- LSN: 50331864
  New Leader: postgresql0
  Reason: no recovery target specified
  TL: 2
  Timestamp: '2023-09-12T11:34:03.148097+00:00'
- LSN: 83886704
  New Leader: postgresql2
  Reason: no recovery target specified
  TL: 3
  Timestamp: '2023-09-12T11:52:26.948134+00:00'
- LSN: 83887280
  New Leader: postgresql0
  Reason: no recovery target specified
  TL: 4
  Timestamp: '2023-09-12T11:53:09.620136+00:00'

patronictl list

Synopsis

list
  [ CLUSTER_NAME [, ... ] ]
  [ --group CITUS_GROUP ]
  [ { -e | --extended } ]
  [ { -t | --timestamp } ]
  [ { -f | --format } { pretty | tsv | json | yaml } ]
  [ { -W | { -w | --watch } TIME } ]

Description

patronictl list affiche des informations sur le cluster Patroni et ses membres.

Les informations suivantes sont incluses dans la sortie :

Cluster Nom du cluster Patroni.

Member Nom du membre Patroni.

Host Hôte sur lequel le membre est situé.

Role Rôle actuel du membre.

Peut être l’un des suivants :

• Leader : le leader actuel d’un cluster Patroni régulier ; ou
• Standby Leader : le leader actuel d’un cluster de secours Patroni ; ou
• Sync Standby : une réplique de secours synchrone d’un cluster Patroni avec le mode synchrone activé ; ou
• Replica : une réplique de secours régulière d’un cluster Patroni.

State État actuel de PostgreSQL dans le membre Patroni.

Quelques exemples parmi les états possibles :

• running : si PostgreSQL est actuellement en cours d’exécution ;
• streaming : si une réplique et PostgreSQL reçoit actuellement des journaux WAL depuis le nœud primaire ;
• in archive recovery : si une réplique et PostgreSQL récupère actuellement les journaux WAL depuis l’archive ;
• stopped : si PostgreSQL a été arrêté ;
• crashed : si PostgreSQL a planté.

TL Timeline actuelle de PostgreSQL dans le membre Patroni.

Receive LSN Dernière position du journal d’avance écrite reçue et synchronisée sur le disque par la réplication en streaming du membre (pg_catalog.pg_last_(xlog|wal)_receive_(location|lsn)()).

Receive Lag Délai de réplication entre la position Receive LSN du membre et son amont, en mégaoctets.

Replay LSN Emplacement du dernier journal d’écriture avancée rejeu durant la récupération du membre (pg_catalog.pg_last_(xlog|wal)_replay_(location|lsn)()).

Replay Lag Délai de réplication entre la position Replay LSN du membre et son amont, en mégaoctets.

En outre, les informations suivantes peuvent être incluses dans la sortie :

System identifier Identifiant système Postgres.

Group ID du groupe Citus.

Pending restart * indique que le nœud nécessite un redémarrage pour que certaines configurations Postgres prennent effet. Une valeur vide indique que le nœud n’a pas besoin de redémarrage.

Scheduled restart Horodatage à partir duquel une redémarrage a été planifié pour l’instance Postgres gérée par le membre Patroni. Une valeur vide indique qu’aucun redémarrage n’est planifié pour le membre.

Tags Contient les balises définies pour le membre Patroni. Une valeur vide indique qu’aucune balise n’a été configurée, ou qu’elles ont été configurées avec des valeurs par défaut.

Scheduled switchover Horodatage auquel un basculement planifié a été prévu pour le cluster Patroni, le cas échéant.

Maintenance mode

Si la surveillance du cluster est actuellement mise en pause.

Note

Affiché dans le pied de tableau.

Affiché uniquement si le cluster est en pause, et que le format de sortie est pretty.

Paramètres

CLUSTER_NAME Nom du cluster Patroni.

Si elle n’est pas fournie, patronictl tentera de la récupérer à partir de la configuration scope, si elle existe.

--group Affiche les informations relatives aux membres du groupe Citus spécifié.

CITUS_GROUP est l’identifiant du groupe Citus.

-e / --extended Affiche des informations étendues.

Forcer l’affichage des attributs Pending restart, Scheduled restart et Tags, même si leur valeur est vide.

-t / --timestamp Affiche une horodatage avant d’afficher les informations sur le cluster et ses membres.

-f / --format Comment formater la liste des événements dans la sortie.

Le format peut être l’un des suivants :

• pretty : affiche l’historique sous forme de tableau élégant ; ou
• tsv : affiche l’historique sous forme d’information tabulaire, les colonnes étant séparées par \t ; ou
• json : affiche l’historique au format JSON ; ou
• yaml : affiche l’historique au format YAML.

La valeur par défaut est pretty.

-W Actualisez automatiquement les informations toutes les 2 secondes.

-w / --watch Actualiser automatiquement les informations à l’intervalle spécifié.

TIME est l’intervalle entre les actualisations, en secondes.

Exemples

Affichez les informations sur le cluster au format lisible :

$ patronictl -c postgres0.yml list batman
+ Cluster: batman (7277694203142172922) -+-----------+----+-------------+-----+------------+-----+
| Member      | Host           | Role    | State     | TL | Receive LSN | Lag | Replay LSN | Lag |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+
| postgresql0 | 127.0.0.1:5432 | Leader  | running   |  5 |             |     |            |     |
| postgresql1 | 127.0.0.1:5433 | Replica | streaming |  5 |   0/40004E8 |   0 |  0/40004E8 |   0 |
| postgresql2 | 127.0.0.1:5434 | Replica | streaming |  5 |   0/40004E8 |   0 |  0/40004E8 |   0 |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+

Affichez les informations sur le cluster au format lisible avec des colonnes étendues :

$ patronictl -c postgres0.yml list batman -e
+ Cluster: batman (7277694203142172922) -+-----------+----+-------------+-----+------------+-----+-----------------+------------------------+-------------------+------+
| Member      | Host           | Role    | State     | TL | Receive LSN | Lag | Replay LSN | Lag | Pending restart | Pending restart reason | Scheduled restart | Tags |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+-----------------+------------------------+-------------------+------+
| postgresql0 | 127.0.0.1:5432 | Leader  | running   |  5 |             |     |            |     |                 |                        |                   |      |
| postgresql1 | 127.0.0.1:5433 | Replica | streaming |  5 |   0/40004E8 |   0 |  0/40004E8 |   0 |                 |                        |                   |      |
| postgresql2 | 127.0.0.1:5434 | Replica | streaming |  5 |   0/40004E8 |   0 |  0/40004E8 |   0 |                 |                        |                   |      |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+-----------------+------------------------+-------------------+------+

Affichez les informations sur le cluster au format YAML, avec l’horodatage de l’exécution :

$ patronictl -c postgres0.yml list batman -f yaml -t
2023-09-12 13:30:48
- Cluster: batman
  Host: 127.0.0.1:5432
  Member: postgresql0
  Role: Leader
  State: running
  TL: 5
- Cluster: batman
  Host: 127.0.0.1:5433
  Receive LSN: 0/40004E8
  Receive Lag: 0
  Replay LSN: 0/40004E8
  Replay Lag: 0
  Member: postgresql1
  Role: Replica
  State: streaming
  TL: 5
- Cluster: batman
  Host: 127.0.0.1:5434
  Receive LSN: 0/40004E8
  Receive Lag: 0
  Replay LSN: 0/40004E8
  Replay Lag: 0
  Member: postgresql2
  Role: Replica
  State: streaming
  TL: 5

patronictl pause

Synopsis

pause
  [ CLUSTER_NAME ]
  [ --group CITUS_GROUP ]
  [ --wait ]

Description

patronictl pause met temporairement le cluster Patroni en mode maintenance et désactive le basculement automatique.

Paramètres

CLUSTER_NAME Nom du cluster Patroni.

Si elle n’est pas fournie, patronictl tentera de la récupérer à partir de la configuration scope, si elle existe.

--group Met en pause le groupe Citus indiqué.

CITUS_GROUP est l’identifiant du groupe Citus.

Si elle n’est pas fournie, patronictl tentera de la récupérer à partir de la configuration citus.group, si elle existe.

--wait Attendez que tous les membres Patroni soient mis en pause avant de restituer le contrôle à l’appelant.

Exemples

Mettez le cluster en mode maintenance, puis attendez que tous les nœuds aient été mis en pause :

$ patronictl -c postgres0.yml pause batman --wait
'pause' request sent, waiting until it is recognized by all nodes
Success: cluster management is paused

patronictl promouvoir-cluster

Synopsis

promote-cluster
  [ CLUSTER_NAME ]
  [ --force ]

Description

patronictl promote-cluster convertit un cluster de secours en cluster Patroni régulier.

La commande supprime la section standby_cluster de la configuration dynamique et attend que le leader fonctionne en tant que primaire. Elle affiche la topologie actuelle du cluster avant de modifier la configuration et demande une confirmation, sauf si --force est utilisé.

Paramètres

CLUSTER_NAME : Nom du cluster Patroni.

Si elle n’est pas fournie, patronictl tentera de la récupérer à partir de la configuration scope, si elle existe.

--force : Indicateur permettant de passer outre les invites de confirmation lors de la promotion du cluster.

Utile pour les scripts.

Exemples

Promouvoir le cluster de secours pour qu’il fonctionne en tant que cluster Patroni régulier :

$ patronictl -c postgres0.yml promote-cluster batman --force

patronictl query

Synopsis

query
  [ CLUSTER_NAME ]
  [ --group CITUS_GROUP ]
  [ { { -r | --role } { leader | primary | standby-leader | replica | standby | any } | { -m | --member } MEMBER_NAME } ]
  [ { -d | --dbname } DBNAME ]
  [ { -U | --username } USERNAME ]
  [ --password ]
  [ --format { pretty | tsv | json | yaml } ]
  [ { { -f | --file } FILE_NAME | { -c | --command } SQL_COMMAND } ]
  [ --delimiter ]
  [ { -W | { -w | --watch } TIME } ]

Description

patronictl query exécute une commande ou un script SQL sur un membre du cluster Patroni.

Paramètres

CLUSTER_NAME Nom du cluster Patroni.

Si elle n’est pas fournie, patronictl tentera de la récupérer à partir de la configuration scope, si elle existe.

--group Interrogez le groupe Citus indiqué.

CITUS_GROUP est l’identifiant du groupe Citus.

-r / --role Choisissez un membre ayant le rôle indiqué.

Le rôle peut être l’un des suivants :

• leader : le leader d’un cluster Patroni régulier ou d’un cluster Patroni en veille ; ou
• primary : le leader d’un cluster Patroni régulier ; ou
• standby-leader : le leader d’un cluster Patroni en veille ; ou
• replica : une réplique d’un cluster Patroni ; ou
• standby : identique à replica ; ou
• any : tout rôle. Identique à omettre ce paramètre.

-m / --member Choisissez un membre ayant le nom indiqué.

MEMBER_NAME est le nom du membre à sélectionner.

-d / --dbname Base de données à laquelle se connecter pour exécuter la requête.

DBNAME est le nom de la base de données. S’il n’est pas fourni, la valeur par défaut est USERNAME.

-U / --username Utilisateur pour se connecter à la base de données.

USERNAME nom de l’utilisateur. S’il n’est pas fourni, la valeur par défaut est l’utilisateur du système d’exploitation exécutant patronictl query.

--password Invite le mot de passe de l’utilisateur connecté.

Comme Patroni utilise libpq, vous pouvez également créer un fichier ~/.pgpass ou définir la variable d’environnement PGPASSWORD.

--format Comment formater la sortie de la requête.

Le format peut être l’un des suivants :

• pretty : affiche les résultats de la requête sous forme de tableau mis en forme ; ou
• tsv : affiche les résultats de la requête sous forme d’information tabulaire, les colonnes étant séparées par \t ; ou
• json : affiche les résultats de la requête au format JSON ; ou
• yaml : affiche les résultats de la requête au format YAML.

La valeur par défaut est tsv.

-f / --file Utilisez un fichier comme source de commandes pour exécuter des requêtes.

FILE_NAME est le chemin d’accès au fichier source.

-c / --command Exécutez la commande SQL fournie dans la requête.

SQL_COMMAND est la commande SQL à exécuter.

--delimiter Le délimiteur utilisé lors de l’affichage des informations au format tsv, ou \t si omis.

-W Exécuter automatiquement la requête toutes les 2 secondes.

-w / --watch Réexécuter automatiquement la requête à l’intervalle spécifié.

TIME indique, en secondes, l’intervalle séparant les réexécutions.

Exemples

Exécutez une commande SQL en tant qu’utilisateur postgres, puis indiquez son mot de passe :

$ patronictl -c postgres0.yml query batman -U postgres --password -c "SELECT now()"
Password:
now
2023-09-12 18:10:53.228084+00:00

Exécutez une commande SQL en tant qu’utilisateur postgres, en prenant le mot de passe depuis la variable d’environnement libpq :

$ PGPASSWORD=patroni patronictl -c postgres0.yml query batman -U postgres -c "SELECT now()"
now
2023-09-12 18:11:37.639500+00:00

Exécutez une commande SQL et affichez au format pretty toutes les 2 secondes :

$ patronictl -c postgres0.yml query batman -c "SELECT now()" --format pretty -W
+----------------------------------+
| now                              |
+----------------------------------+
| 2023-09-12 18:12:16.716235+00:00 |
+----------------------------------+
+----------------------------------+
| now                              |
+----------------------------------+
| 2023-09-12 18:12:18.732645+00:00 |
+----------------------------------+
+----------------------------------+
| now                              |
+----------------------------------+
| 2023-09-12 18:12:20.750573+00:00 |
+----------------------------------+

Exécutez une commande SQL sur la base de données test et affichez la sortie au format YAML :

$ patronictl -c postgres0.yml query batman -d test -c "SELECT now() AS column_1, 'test' AS column_2" --format yaml
- column_1: 2023-09-12 18:14:22.052060+00:00
  column_2: test

Exécutez une commande SQL sur le membre postgresql2 :

$ patronictl -c postgres0.yml query batman -m postgresql2 -c "SHOW port"
port
5434

Exécutez une commande SQL sur l’un des serveurs de secours :

$ patronictl -c postgres0.yml query batman -r replica -c "SHOW port"
port
5433

patronictl reinit

Synopsis

reinit
  CLUSTER_NAME
  [ MEMBER_NAME [, ... ] ]
  [ --group CITUS_GROUP ]
  [ --wait ]
  [ --force ]
  [ --from-leader ]

Description

patronictl reinit reconstruit une instance Postgres en mode standby gérée par une réplique membre du cluster Patroni.

Paramètres

CLUSTER_NAME Nom du cluster Patroni.

MEMBER_NAME Nom du membre réplique pour lequel l’instance Postgres sera reconstruite.

Plusieurs répliques peuvent être spécifiées. Si aucune réplique n’est spécifiée, la commande ne fait rien.

--group
Reconstruit un membre réplica du groupe Citus indiqué.

CITUS_GROUP est l’identifiant du groupe Citus.

--wait Attendez que la réinitialisation du(nœud) de secours Postgres soit terminée.

--force Indicateur permettant de passer outre les invites de confirmation lors de la reconstruction des instances secondaires Postgres.

--from-leader Indicateur permettant d’obtenir un basebackup directement depuis le leader.

Utile pour les scripts.

Exemples

Demandez une reconstruction de toutes les répliques du cluster Patroni et renvoyez immédiatement le contrôle à l’appelant :

$ patronictl -c postgres0.yml reinit batman postgresql1 postgresql2 --force
+ Cluster: batman (7277694203142172922) -+-----------+----+-------------+-----+------------+-----+
| Member      | Host           | Role    | State     | TL | Receive LSN | Lag | Replay LSN | Lag |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+
| postgresql0 | 127.0.0.1:5432 | Leader  | running   |  5 |             |     |            |     |
| postgresql1 | 127.0.0.1:5433 | Replica | streaming |  5 |   0/40004E8 |   0 |  0/40004E8 |   0 |
| postgresql2 | 127.0.0.1:5434 | Replica | streaming |  5 |   0/40004E8 |   0 |  0/40004E8 |   0 |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+
Success: reinitialize for member postgresql1
Success: reinitialize for member postgresql2

Demandez une reconstruction de postgresql2 et attendez sa finalisation :

$ patronictl -c postgres0.yml reinit batman postgresql2 --wait --force
+ Cluster: batman (7277694203142172922) -+-----------+----+-------------+-----+------------+-----+
| Member      | Host           | Role    | State     | TL | Receive LSN | Lag | Replay LSN | Lag |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+
| postgresql0 | 127.0.0.1:5432 | Leader  | running   |  5 |             |     |            |     |
| postgresql1 | 127.0.0.1:5433 | Replica | streaming |  5 |   0/40004E8 |   0 |  0/40004E8 |   0 |
| postgresql2 | 127.0.0.1:5434 | Replica | streaming |  5 |   0/40004E8 |   0 |  0/40004E8 |   0 |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+
Success: reinitialize for member postgresql2
Waiting for reinitialize to complete on: postgresql2
Reinitialize is completed on: postgresql2

Demandez une reconstruction de postgresql2 et obtenez le basebackup directement depuis le leader :

$ patronictl -c postgres0.yml reinit batman postgresql2 --from-leader
+ Cluster: batman (7277694203142172922) -+-----------+----+-------------+-----+------------+-----+
| Member      | Host           | Role    | State     | TL | Receive LSN | Lag | Replay LSN | Lag |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+
| postgresql0 | 127.0.0.1:5432 | Leader  | running   |  5 |             |     |            |     |
| postgresql1 | 127.0.0.1:5433 | Replica | streaming |  5 |   0/40004E8 |   0 |  0/40004E8 |   0 |
| postgresql2 | 127.0.0.1:5434 | Replica | streaming |  5 |   0/40004E8 |   0 |  0/40004E8 |   0 |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+
Success: reinitialize for member postgresql2

patronictl reload

Synopsis

reload
  CLUSTER_NAME
  [ MEMBER_NAME [, ... ] ]
  [ --group CITUS_GROUP ]
  [ { -r | --role } { leader | primary | standby-leader | replica | standby | any } ]
  [ --force ]

Description

patronictl reload demande un rechargement de la configuration locale pour un ou plusieurs membres Patroni.

Il déclenche également pg_ctl reload sur l’instance Postgres gérée, même si rien n’a changé.

Paramètres

CLUSTER_NAME Nom du cluster Patroni.

MEMBER_NAME Demander un rechargement de la configuration locale pour le ou les membres Patroni indiqués.

Plusieurs membres peuvent être spécifiés. Si aucun membre n’est spécifié, tous les membres sont pris en compte.

--group Demandez un rechargement des membres du groupe Citus donné.

CITUS_GROUP est l’identifiant du groupe Citus.

-r / --role Sélectionne les membres ayant le rôle indiqué.

Le rôle peut être l’un des suivants :

• leader : le leader d’un cluster Patroni régulier ou d’un cluster Patroni en veille ; ou
• primary : le leader d’un cluster Patroni régulier ; ou
• standby-leader : le leader d’un cluster Patroni en veille ; ou
• replica : une réplique d’un cluster Patroni ; ou
• standby : identique à replica ; ou
• any : tout rôle. Identique à omettre ce paramètre.

--force Indicateur permettant de passer outre les invites de confirmation lors de la demande de rechargement de la configuration locale.

Utile pour les scripts.

Exemples

Demandez un rechargement de la configuration locale de tous les membres du cluster Patroni :

$ patronictl -c postgres0.yml reload batman --force
+ Cluster: batman (7277694203142172922) -+-----------+----+-------------+-----+------------+-----+
| Member      | Host           | Role    | State     | TL | Receive LSN | Lag | Replay LSN | Lag |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+
| postgresql0 | 127.0.0.1:5432 | Leader  | running   |  5 |             |     |            |     |
| postgresql1 | 127.0.0.1:5433 | Replica | streaming |  5 |   0/40004E8 |   0 |  0/40004E8 |   0 |
| postgresql2 | 127.0.0.1:5434 | Replica | streaming |  5 |   0/40004E8 |   0 |  0/40004E8 |   0 |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+
Reload request received for member postgresql0 and will be processed within 10 seconds
Reload request received for member postgresql1 and will be processed within 10 seconds
Reload request received for member postgresql2 and will be processed within 10 seconds

patronictl supprimer

Synopsis

remove
  CLUSTER_NAME
  [ --group CITUS_GROUP ]
  [ { -f | --format } { pretty | tsv | json | yaml } ]

Description

patronictl remove supprime les informations du cluster du DCS.

Il s’agit d’une action interactive.

[!AVERTISSEMENT]

Cette opération supprimera les informations du cluster Patroni dans le DCS.

Paramètres

CLUSTER_NAME Nom du cluster Patroni.

--group Supprimez les informations relatives au cluster Patroni associées au groupe Citus donné.

CITUS_GROUP est l’identifiant du groupe Citus.

-f / --format Comment formater la liste des membres dans la sortie lors de la demande de confirmation.

Le format peut être l’un des suivants :

• pretty : affiche les membres sous forme de tableau mis en forme ; ou
• tsv : affiche les membres sous forme de tableaux, les colonnes étant séparées par \t ; ou
• json : affiche les membres au format JSON ; ou
• yaml : affiche les membres au format YAML.

La valeur par défaut est pretty.

Exemples

Supprimer les informations relatives au cluster Patroni batman du DCS :

$ patronictl -c postgres0.yml remove batman
+ Cluster: batman (7277694203142172922) -+-----------+----+-------------+-----+------------+-----+
| Member      | Host           | Role    | State     | TL | Receive LSN | Lag | Replay LSN | Lag |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+
| postgresql0 | 127.0.0.1:5432 | Leader  | running   |  5 |             |     |            |     |
| postgresql1 | 127.0.0.1:5433 | Replica | streaming |  5 |   0/40004E8 |   0 |  0/40004E8 |   0 |
| postgresql2 | 127.0.0.1:5434 | Replica | streaming |  5 |   0/40004E8 |   0 |  0/40004E8 |   0 |
+-------------+----------------+---------+-----------+----+-------------+-----+------------+-----+
Please confirm the cluster name to remove: batman
You are about to remove all information in DCS for batman, please type: "Yes I am aware": Yes I am aware
This cluster currently is healthy. Please specify the leader name to continue: postgresql0