Composants communautaires PostgreSQL on PIG.CENTER

Notes de version pgBadger 13.x

Mon, 01 Jan 0001 00:00:00 +0000

Ces entrées conservent l’intégralité de l’historique des modifications upstream pour pgBadger 13.x, du plus récent au plus ancien.

v13.2 · 2025-12-29

Il s’agit d’une version de maintenance de pgBadger qui corrige des problèmes et applique des correctifs signalés par les utilisateurs depuis la dernière version.

Corriger la normalisation qui ne traitait pas correctement les chaînes entre guillemets simples équilibrées, y compris les guillemets échappés à l’intérieur. Remerciements à Bertrand Bourgier pour le rapport.
Corriger les exigences relatives aux espaces réservés dans la documentation.
Corriger le cas où aucune entrée d’exemple d’erreur n’était rapportée. Remerciements à john doe pour le rapport.
Corriger un problème potentiel de priorité entre ! et %s. Remerciements à Luca Santarelli et Philipp Trulson pour le rapport.
Mettre à jour le code pgFormatter à la version 5.9
Ajouter une action CI GitHub pour le test lors de la poussée de commit.
Corriger l’analyse du placeholder %r dans log_line_prefix. Remerciements à nike7o0 pour le rapport.
Corriger l’avertissement relatif à une valeur non initialisée. Remerciements à Ales Zeleny pour le rapport.
Améliorer la documentation des options SSH pour l’analyse des journaux PostgreSQL avec des exemples. Remerciements à Ulrich Konrad pour le correctif.
Ajouter la commande –ssh-sudo pour exécuter des commandes en SSH en tant que sudo. Remerciements à Andrew Jackson pour le correctif.
Corriger un problème potentiel de priorité entre ! et l’égalité de chaîne. Remerciements à Adrien Nayrat pour le rapport.
Corriger l’analyse des statistiques de pgbouncer. Remerciements à mrgtt pour le rapport.

v13.1 · 2025-03-16

Il s’agit d’une version de maintenance de pgBadger qui corrige des problèmes signalés par les utilisateurs depuis la dernière version et ajoute certaines nouvelles fonctionnalités :

Actualités

Mon, 01 Jan 0001 00:00:00 +0000

pgBackRest 2.59.1 publié

17 août 2026

La communauté pgBackRest est heureuse d’annoncer la sortie de pgBackRest 2.59.1, la dernière version de la solution fiable, facile à utiliser, de sauvegarde et de restauration, pouvant s’adapter sans heurt aux plus grandes bases de données et charges de travail.

pgBackRest prend en charge un ensemble complet de fonctionnalités pour gérer votre infrastructure de sauvegarde et de récupération, notamment : sauvegarde/restauration en parallèle, sauvegardes complètes/différentielles/sauvegardes incrémentielles, sauvegarde incrémentielle par bloc, plusieurs dépôts, restauration par delta, archivage asynchrone en parallèle, protection contre les logiciels malveillants/rançongiciels, sommes de contrôle par fichier, sommes de contrôle par page (lorsqu’activées) validées pendant la sauvegarde, plusieurs types de compression, chiffrement, reprise partielle/échouée de sauvegarde, sauvegarde depuis un serveur secondaire, prise en charge des espaces de table et des liens, prise en charge de S3/Azure/GCS/SFTP, expiration des sauvegardes, opérations locales/distantes via SSH ou TLS, configuration flexible, et bien plus encore.

Commande d'annotation (annotate)

Mon, 01 Jan 0001 00:00:00 +0000

Les annotations incluses avec la commande backup peuvent être ajoutées, modifiées ou supprimées ultérieurement à l’aide de la commande annotate.

Options de commande

Option d’annotation de sauvegarde (`--annotation`)

Ajoutez des paires clé/valeur définies par l’utilisateur à la sauvegarde.

Les utilisateurs peuvent attacher des paires clé/valeur explicatives à la sauvegarde. Cette option peut être utilisée plusieurs fois pour attacher plusieurs annotations.

Paramètres de configuration dynamique

Mon, 01 Jan 0001 00:00:00 +0000

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]

Paramètres de configuration YAML

Mon, 01 Jan 0001 00:00:00 +0000

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

Fonctionnalités

Mon, 01 Jan 0001 00:00:00 +0000

Plusieurs niveaux de sévérité lors de la rotation des connexions :

Pooling de sessions : Méthode la moins intrusive. Lorsqu’un client se connecte, une connexion serveur lui est attribuée pour toute la durée de sa connexion. Lorsque le client se déconnecte, la connexion serveur est remise dans le pool. Ce mode prend en charge toutes les fonctionnalités de PostgreSQL.

Pooling de transactions : Une connexion serveur est attribuée à un client uniquement pendant une transaction. Lorsque PgBouncer détecte la fin de la transaction, le serveur est remis dans le pool. Ce mode désactive quelques fonctionnalités basées sur la session de PostgreSQL. Vous ne pouvez l’utiliser que si l’application coopère en ne utilisant pas les fonctionnalités qui causent des incompatibilités. Consultez le tableau ci-dessous pour les fonctionnalités incompatibles.

Guide de démarrage

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

Mon, 01 Jan 0001 00:00:00 +0000

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.

Notes de version de pgBadger 12.x

Mon, 01 Jan 0001 00:00:00 +0000

Ces entrées conservent l’intégralité de l’historique des modifications upstream pour pgBadger 12.x, du plus récent au plus ancien.

v12.4 · 2023-12-25

Il s’agit d’une version de maintenance de pgBadger qui corrige les problèmes signalés par les utilisateurs depuis la dernière version.

Correction du rapport pgbouncer avec la version 1.21. Remerciements à Ales Zeleny pour le correctif.
Empêcher que le parallélisme du fichier Perl dépasse le nombre de fichiers. Remerciements à maliangzhu pour le signalement.
Correction du test de régression cassé depuis la version 12.3. Remerciements à ieshin pour le signalement.
Correction des cas où les entrées LOG étaient comptées comme des entrées de niveau d’erreur. Remerciements à Matti Linnanvuori pour le signalement.

v12.3 · 2023-11-27

Il s’agit d’une version de maintenance de pgBadger qui corrige des problèmes signalés par les utilisateurs depuis la dernière version. Elle introduit également quelques nouvelles fonctionnalités :

Commande d’archive (archive-get)

Mon, 01 Jan 0001 00:00:00 +0000

Cette commande est utilisée par PostgreSQL pour effectuer une restauration, une récupération jusqu’à un instant précis (PITR), ou en tant qu’alternative au streaming afin de maintenir une réplique à jour. Les segments WAL sont requis pour la récupération de PostgreSQL ou pour maintenir une réplique.

Lorsque plusieurs dépôts sont configurés, les fichiers WAL seront récupérés dans l’ordre de priorité des dépôts (par exemple repo1, repo2, etc.). En général, il est préférable que les dépôts plus rapides ou moins coûteux aient une priorité plus élevée. Si un dépôt est spécifié avec l’option --repo, seul ce dépôt sera recherché.

Configuration : pgbouncer.ini

Mon, 01 Jan 0001 00:00:00 +0000

Description

Le fichier de configuration est au format « ini ». Les noms de section sont entre [ et ]. Les lignes commençant par ; ou # sont traitées comme des commentaires et ignorées. Les caractères ; et # ne sont pas reconnus comme spéciaux lorsqu’ils apparaissent ultérieurement dans la ligne.

Paramètres génériques

fichier_journal

Spécifie le fichier de journalisation. En mode démon (-d), il faut définir soit ce paramètre, soit syslog.

Guide utilisateur (Debian/Ubuntu)

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

Ce guide utilisateur est conçu pour être suivi séquentiellement, du début à la fin — chaque section dépend de la précédente. Par exemple, la section Restauration repose sur la configuration effectuée dans la section Démarrage rapide . Une fois pgBackRest en fonctionnement, il est possible de sauter des sections, mais il est recommandé de suivre le guide dans l’ordre lors de la première utilisation.

Bien que les exemples de ce guide soient destinés à Debian/Ubuntu et à PostgreSQL 17, il devrait être relativement facile de les appliquer à toute distribution Unix et toute version de PostgreSQL. Les seules commandes spécifiques au système d’exploitation sont celles permettant de créer, démarrer, arrêter et supprimer des clusters PostgreSQL. Les commandes pgBackRest seront identiques sur tout système Unix, bien que l’emplacement de l’exécutable puisse varier. Bien que pgBackRest cherche à fonctionner de manière cohérente sur les différentes versions de PostgreSQL, certaines différences subtiles entre versions de PostgreSQL peuvent apparaître dans ce guide lors de l’illustration de certains exemples, par exemple les chemins ou noms de fichiers de PostgreSQL, ainsi que les paramètres.

Installation

Mon, 01 Jan 0001 00:00:00 +0000

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.

Fundamentaux de la répartition de charge

Mon, 01 Jan 0001 00:00:00 +0000

Ce document présente HAProxy à l’intention de tous ceux qui ne le connaissent pas, ainsi que de ceux qui souhaitent le redécouvrir après avoir utilisé des versions antérieures. Son objectif principal est de fournir à l’utilisateur toutes les informations nécessaires pour décider si HAProxy correspond ou non à ses besoins. Les utilisateurs avancés pourront y trouver certaines solutions à des idées qu’ils avaient eues, simplement parce qu’ils ignoraient une fonctionnalité récente. Des indications de dimensionnement sont également fournies, le cycle de vie du produit est expliqué, ainsi que des comparaisons avec des produits partiellement similaires.

Téléchargement et installation

Mon, 01 Jan 0001 00:00:00 +0000

Choisissez un canal de distribution

Channel	Utilisation	Emplacement
Version officielle	Archives sources et notes de version	GitHub Releases
Paquet RPM	Distributions Linux basées sur RPM	PostgreSQL Yum Repository
Paquet Debian/Ubuntu	Distributions Linux basées sur APT	PostgreSQL Apt Repository
Code source de développement	Code actuel non encore publié	darold/pgbadger

La version de documentation disponible sur ce site est basée sur l’arbre source 13.2. Vérifiez toujours la page de publication avant de télécharger : la version locale est intentionnellement figée, tandis que les versions upstream évoluent continuellement.

Notes de version de pgBadger 11.x

Mon, 01 Jan 0001 00:00:00 +0000

Ces entrées conservent l’intégralité de l’historique des modifications upstream pour pgBadger 11.x, du plus récent au plus ancien.

v11.8 · 2022-04-08

Cette version de pgBadger corrige certains problèmes signalés par les utilisateurs au cours des trois derniers mois, en particulier deux correctifs concernant la détection des nouvelles entrées de journal en mode incrémentiel.

Corriger la détection des nouvelles entrées de journal avec horodatage lorsque le format milliseconde (%m) ou époque (%n) était utilisé dans log_line_prefix.
Corriger la détection des nouvelles entrées de journal dans le fichier local lorsque le mode multiprocessus n’était pas utilisé.

Voici la liste complète des modifications et des remerciements :

Qu'est-ce qu'HAProxy et comment il fonctionne

Mon, 01 Jan 0001 00:00:00 +0000

La graphie « HAProxy » désigne le produit, tandis que « haproxy » désigne le programme exécutable, le paquet logiciel ou un processus. Ces graphies sont toutefois couramment utilisées dans chaque contexte et se prononcent H-A-Proxy. À l’origine, « haproxy » signifiait « high availability proxy » et le nom s’écrivait en deux mots distincts ; aujourd’hui, il ne signifie plus rien d’autre que « HAProxy ».

Commande de poussée d'archive (archive-push)

Mon, 01 Jan 0001 00:00:00 +0000

Accepte un segment WAL de PostgreSQL et l’archive dans chaque dépôt défini par l’option indexée repo-path (voir la section Repository pour obtenir des informations sur la configuration des dépôts). Le segment WAL peut être envoyé immédiatement à l’archive ou stocké localement, selon la valeur de archive-async. En cas de configuration de plusieurs dépôts, archive-push tentera d’envoyer à autant de dépôts que possible.

Le archive-push est destiné à être configuré et appelé par PostgreSQL. Voir Configurer la sauvegarde d’archive pour un exemple.

Paramètres de configuration de l'environnement

Mon, 01 Jan 0001 00:00:00 +0000

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]

Guide utilisateur (RHEL)

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

Bien que les exemples de ce guide soient destinés à RHEL et à PostgreSQL 14, il devrait être relativement facile de les appliquer à toute distribution Unix et toute version de PostgreSQL. Les seules commandes spécifiques au système d’exploitation sont celles permettant de créer, démarrer, arrêter et supprimer des clusters PostgreSQL. Les commandes pgBackRest seront identiques sur tout système Unix, bien que l’emplacement de l’exécutable puisse varier. Bien que pgBackRest cherche à fonctionner de manière cohérente sur les différentes versions de PostgreSQL, certaines différences subtiles entre versions de PostgreSQL peuvent apparaître dans ce guide lors de l’illustration de certains exemples, par exemple les chemins ou noms de fichiers de PostgreSQL, ainsi que les paramètres.

Référence en ligne de commande

Mon, 01 Jan 0001 00:00:00 +0000

Cette page conserve la référence de commande générée à partir de la source upstream verrouillée. Les noms d’option et le texte d’aide restent tels quels afin de pouvoir être comparés directement avec pgbadger --help.

Utilisation et options

Utilisation : pgBadger [options] fichier_journal […]

PostgreSQL log analyzer with fully detailed reports and graphs.

Arguments :

logfile can be a single log file, a list of files, or a shell command
returning a list of files. If you want to pass log content from stdin
use - as filename. Note that input from stdin will not work with csvlog.

Options :

Usage : pgbouncer commande

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis

pgbouncer [-d][-R][-v][-u user] <pgbouncer.ini>
pgbouncer -V|-h

Sous Windows, les options sont :

pgbouncer.exe [-v][-u user] <pgbouncer.ini>
pgbouncer.exe -V|-h

Options supplémentaires pour la configuration d’un service Windows :

pgbouncer.exe --regservice <pgbouncer.ini>
pgbouncer.exe --unregservice <pgbouncer.ini>

Description

pgbouncer est un pooler de connexions PostgreSQL. Toute application cliente peut se connecter à pgbouncer comme s’il était un serveur PostgreSQL, et pgbouncer établira une connexion vers le serveur réel, ou réutilisera l’une de ses connexions existantes.

Notes de version pgBadger 10.x

Mon, 01 Jan 0001 00:00:00 +0000

Ces entrées conservent l’intégralité de l’historique des modifications upstream pour pgBadger 10.x, du plus récent au plus ancien.

v10.3 · 2019-02-14

Cette version de pgBadger est une mise à jour de maintenance qui corrige certains problèmes de détection automatique du format de journalisation, ainsi qu’un autre problème de lecture des journaux de pgBouncer signalé par les utilisateurs. Une nouvelle fonctionnalité est également disponible :

The -o | --outfile option can now be used multiple time to dump
output in several format in a single command. For example:
 pgbadger -o out.html -o out.json /log/pgsql-11.log
will create two reports in html and json format saved in the
two corresponding files.

Il existe également quelques corrections de bogues et améliorations de fonctionnalités.

API REST Patroni

Mon, 01 Jan 0001 00:00:00 +0000

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.

Commande de sauvegarde (backup)

Mon, 01 Jan 0001 00:00:00 +0000

Lorsque plusieurs dépôts sont configurés, pgBackRest effectuera la sauvegarde vers le dépôt de priorité la plus élevée (par exemple repo1) sauf si l’option --repo est spécifiée.

pgBackRest ne dispose pas de planificateur intégré, il est donc préférable de l’exécuter depuis cron ou un autre mécanisme de planification.

Consultez Effectuer une sauvegarde pour plus de détails et d’exemples.

Options de commande

Option d’annotation de sauvegarde (`--annotation`)

Ajoutez des paires clé/valeur définies par l’utilisateur à la sauvegarde.

Fonctionnalités de base

Mon, 01 Jan 0001 00:00:00 +0000

Cette section énumère un certain nombre de fonctionnalités implémentées par HAProxy, certaines étant généralement attendues d’un répartiteur de charge moderne, et d’autres constituant un avantage direct de l’architecture d’HAProxy. Les fonctionnalités avancées seront détaillées dans la section suivante.

3.3.1. Fonctionnalités de base : Proxys

Le proxy consiste à transférer des données entre un client et un serveur via deux connexions indépendantes. Les fonctionnalités de base suivantes sont prises en charge par HAProxy en matière de proxy et de gestion des connexions :

Compilation et installation de PgBouncer

Mon, 01 Jan 0001 00:00:00 +0000

Construction

PgBouncer dépend de quelques éléments pour être compilé :

GNU Make 3.81+
Libevent 2.0+
pkg-config
OpenSSL 1.0.1+ pour la prise en charge du TLS
(facultatif) c-ares en tant qu’alternative à evdns de Libevent
(facultatif) bibliothèques LDAP
(facultatif) bibliothèques PAM

Lorsque les dépendances sont installées, exécutez simplement :

$ ./configure --prefix=/usr/local
$ make
$ make install

Si vous compilez à partir de Git, ou si vous compilez pour Windows, veuillez consulter les instructions de compilation spécifiques ci-dessous.

Configuration de journalisation de PostgreSQL

Mon, 01 Jan 0001 00:00:00 +0000

pgBadger ne peut rapporter que les informations écrites par PostgreSQL dans les journaux. Commencez par un préfixe analysable et une politique de journalisation explicite des requêtes, puis ajoutez les événements opérationnels que vous souhaitez analyser.

Journalisation minimale des requêtes

Pour inclure le texte et la durée de la requête, activez la journalisation des instructions basée sur la durée :

log_min_duration_statement = 0

0 enregistre chaque instruction terminée. Sur un serveur très sollicité, sélectionnez une valeur plus élevée en millisecondes afin de contrôler le volume des journaux. Mesurez la surcharge et la croissance du stockage avant d’activer une seuil faible en production.

Notes de version de pgBadger 9.x

Mon, 01 Jan 0001 00:00:00 +0000

Ces entrées conservent l’intégralité de l’historique des modifications upstream pour pgBadger 9.x, du plus récent au plus ancien.

v9.2 · 2017-07-27

Cette version de pgBadger est une mise à jour de maintenance qui ajoute quelques nouvelles fonctionnalités.

Ajouter un rapport de distance entre les points de contrôle et une estimation.
Ajouter le support des mots-clés AWS Redshift dans le formateur de code SQL.
Ajouter la détection automatique du format du fichier journal en mode distant afin de permettre l’analyse distante du fichier journal de pgbouncer conjointement avec le fichier journal PostgreSQL.

Il existe également quelques corrections de bogues et améliorations de fonctionnalités.

Commande de vérification (check)

Mon, 01 Jan 0001 00:00:00 +0000

La commande check vérifie que pgBackRest et le paramètre archive_command sont correctement configurés pour l’archivage et les sauvegardes du stanza spécifié. Elle tente de vérifier tous les dépôts et bases de données configurés pour l’hôte sur lequel la commande est exécutée. Elle détecte les mauvaises configurations, en particulier celles relatives à l’archivage, qui entraînent des sauvegardes incomplètes car des segments WAL requis n’ont pas atteint l’archive. La commande peut être exécutée sur l’hôte PostgreSQL ou sur l’hôte dépôt. Elle peut également être exécutée sur l’hôte de basculement, toutefois, comme les opérations pg_switch_xlog()/pg_switch_wal() ne peuvent pas être effectuées sur le basculement, la commande ne testera que la configuration du dépôt.

Référence de configuration

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

pgBackRest peut être utilisé entièrement à l’aide de paramètres en ligne de commande, mais un fichier de configuration est plus pratique pour les installations complexes ou celles qui définissent de nombreux paramètres. L’emplacement par défaut du fichier de configuration est /etc/pgbackrest/pgbackrest.conf. Si aucun fichier n’existe à cet emplacement, l’ancien emplacement par défaut de /etc/pgbackrest.conf sera vérifié.

Les types d’option suivants sont utilisés :

Chaîne : Une chaîne de texte, couramment utilisée comme identifiant, mot de passe, etc.

Fonctionnalités standard

Mon, 01 Jan 0001 00:00:00 +0000

Dans cette section, sont énumérées certaines fonctionnalités très couramment utilisées avec HAProxy mais qui ne sont pas nécessairement disponibles sur d’autres répartiteurs de charge.

3.4.1. Fonctionnalités standard : Échantillonnage et conversion d’informations

HAProxy prend en charge l’extraction d’échantillons à l’aide d’une large gamme de « fonctions d’extraction d’échantillon ». Le principe consiste à extraire des éléments d’information appelés échantillons, destinés à une utilisation immédiate. Cela est utilisé pour la persistance de session, la création de conditions, la génération d’informations dans les journaux ou l’enrichissement des en-têtes HTTP.

patronictl

Mon, 01 Jan 0001 00:00:00 +0000

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.

Source Versions Téléchargement

Mon, 01 Jan 0001 00:00:00 +0000

PgBouncer 1.25

Fichier	Date	Taille	SHA256
pgbouncer-1.25.2.tar.gz	2026-05-08	865371 octets	sha256
pgbouncer-1.25.1.tar.gz	2025-12-03	864801 octets	sha256
pgbouncer-1.25.0.tar.gz	2025-11-09	863322 octets	sha256

PgBouncer 1.24

Fichier	Date	Taille	SHA256
pgbouncer-1.24.1.tar.gz	2025-04-16	717796 octets	sha256
pgbouncer-1.24.0.tar.gz	2025-01-10	706573 octets	sha256

PgBouncer 1.23

Fichier	Date	Taille	SHA256
pgbouncer-1.23.1.tar.gz	2024-08-02	700025 octets	sha256
pgbouncer-1.23.0.tar.gz	2024-07-03	694845 octets	sha256

PgBouncer 1.22

Fichier	Date	Taille	SHA256
pgbouncer-1.22.1.tar.gz	2024-03-04	677351 octets	sha256
pgbouncer-1.22.0.tar.gz	2024-01-31	670589 octets	sha256

PgBouncer 1.21

Fichier	Date	Taille	SHA256
pgbouncer-1.21.0.tar.gz	2023-10-16	668211 octets	sha256

PgBouncer 1.20

Fichier	Date	Taille	SHA256
pgbouncer-1.20.1.tar.gz	2023-08-09	638844 octets	sha256
pgbouncer-1.20.0.tar.gz	2023-07-20	638020 octets	sha256

PgBouncer 1.19

Fichier	Date	Taille	SHA256
pgbouncer-1.19.1.tar.gz	2023-05-31	623569 octets	sha256
pgbouncer-1.19.0.tar.gz	2023-05-04	616947 octets	sha256

PgBouncer 1.18

Fichier	Date	Taille	SHA256
pgbouncer-1.18.0.tar.gz	2022-12-12	600825 octets	sha256

PgBouncer 1.17

Fichier	Date	Taille	SHA256
pgbouncer-1.17.0.tar.gz	2022-03-23	598294 octets	sha256

PgBouncer 1.16

Fichier	Date	Taille	SHA256
pgbouncer-1.16.1.tar.gz	2021-11-11	591450 octets	sha256
pgbouncer-1.16.0.tar.gz	2021-08-09	592136 octets	sha256

PgBouncer 1.15

Fichier	Date	Taille	SHA256
pgbouncer-1.15.0.tar.gz	2020-11-19	588042 octets	sha256

PgBouncer 1.14

Fichier	Date	Taille	SHA256
pgbouncer-1.14.0.tar.gz	2020-06-11	578955 octets	sha256

PgBouncer 1.13

Fichier	Date	Taille	SHA256
pgbouncer-1.13.0.tar.gz	2020-04-27	574955 octets	sha256

PgBouncer 1.12

Fichier	Date	Taille	SHA256
pgbouncer-1.12.0.tar.gz	2019-10-17	567465 octets	sha256

PgBouncer 1.11

Fichier	Date	Taille	SHA256
pgbouncer-1.11.0.tar.gz	2019-08-27	571414 octets	sha256

PgBouncer 1.10

Fichier	Date	Taille	SHA256
pgbouncer-1.10.0.tar.gz	2019-07-01	480571 octets	sha256

PgBouncer 1.9

Fichier	Date	Taille	SHA256
pgbouncer-1.9.0.tar.gz	2018-08-13	469300 octets	sha256

PgBouncer 1.8

Fichier	Date	Taille	SHA256
pgbouncer-1.8.1.tar.gz	2017-12-20	465930 octets	sha256
pgbouncer-1.8.tar.gz	2017-12-19	465612 octets	sha256

PgBouncer 1.7

Fichier	Date	Taille	SHA256
pgbouncer-1.7.2.tar.gz	2016-02-26	462374 octets	sha256
pgbouncer-1.7.1.tar.gz	2016-02-18	461903 octets	sha256
pgbouncer-1.7.tar.gz	2015-12-18	459080 octets	sha256

PgBouncer 1.6

Fichier	Date	Taille	SHA256
pgbouncer-1.6.1.tar.gz	2015-09-03	431076 octets	sha256
pgbouncer-1.6.tar.gz	2015-08-01	412700 octets	sha256

PgBouncer 1.5

Fichier	Date	Taille	SHA256
pgbouncer-1.5.5.tar.gz	2015-04-09	336145 octets	sha256
pgbouncer-1.5.4.tar.gz	2012-11-28	339610 octets	sha256
pgbouncer-1.5.3.tar.gz	2012-09-12	339013 octets	sha256
pgbouncer-1.5.2.tar.gz	2012-05-29	335338 octets	sha256
pgbouncer-1.5.1.tar.gz	2012-04-17	334413 octets	sha256
pgbouncer-1.5.tar.gz	2012-01-05	411488 octets	sha256

PgBouncer 1.4

Fichier	Date	Taille	SHA256
pgbouncer-1.4.2.tgz	2011-06-16	283204 octets	sha256
pgbouncer-1.4.1.tgz	2011-04-01	282728 octets	sha256
pgbouncer-1.4.tgz	2011-01-11	231691 octets	sha256

PgBouncer 1.3

Fichier	Date	Taille	SHA256
pgbouncer-1.3.4.tgz	2010-09-09	167957 octets	sha256
pgbouncer-1.3.3.tgz	2010-05-10	167476 octets	sha256
pgbouncer-1.3.2.tgz	2010-03-15	166756 octets	sha256
pgbouncer-1.3.1.tgz	2009-07-06	161518 octets	sha256
pgbouncer-1.3.tgz	2009-02-18	160154 octets	sha256

PgBouncer 1.2

Fichier	Date	Taille	SHA256
pgbouncer-1.2.3.tgz	2008-08-08	145372 octets	sha256
pgbouncer-1.2.2.tgz	2008-08-06	145017 octets	sha256
pgbouncer-1.2.1.tgz	2008-08-04	144903 octets	sha256
pgbouncer-1.2.tgz	2008-07-29	143915 octets	sha256

PgBouncer 1.1

Fichier	Date	Taille	SHA256
pgbouncer-1.1.2.tgz	2007-12-10	122054 octets	sha256
pgbouncer-1.1.1.tgz	2007-10-26	121042 octets	sha256
pgbouncer-1.1.tgz	2007-10-09	120462 octets	sha256

PgBouncer 1.0

Fichier	Date	Taille	SHA256
pgbouncer-1.0.8.tgz	2007-06-18	93636 octets	sha256
pgbouncer-1.0.7.tgz	2007-04-19	93086 octets	sha256
pgbouncer-1.0.6.tgz	2007-04-12	92244 octets	sha256
pgbouncer-1.0.5.tgz	2007-04-11	91934 octets	sha256
pgbouncer-1.0.4.tgz	2007-04-11	91889 octets	sha256
pgbouncer-1.0.3.tgz	2007-04-11	91489 octets	sha256
pgbouncer-1.0.2.tgz	2007-03-28	90555 octets	sha256
pgbouncer-1.0.1.tgz	2007-03-15	89609 octets	sha256
pgbouncer-1.0.tgz	2007-03-13	88587 octets	sha256

Paquets binaires

Plusieurs distributions de systèmes d’exploitation proposent leur propre paquet ou port de PgBouncer. Il est donc recommandé de vérifier en premier lieu si celui-ci est déjà disponible sur votre système d’exploitation.

Traitement parallèle

Mon, 01 Jan 0001 00:00:00 +0000

pgBadger dispose de deux modes de traitement parallèle complémentaires. Choisissez selon la forme de l’entrée, et non simplement selon le nombre de processeurs.

Option	Unité parallèle	Meilleur ajustement	Contrainte principale
`-j N` / `--jobs N`	tronçons d’un fichier journal	un seul fichier journal volumineux et accessible par recherche	les limites des tronçons peuvent dupliquer ou omettre un petit nombre de requêtes
`-J N` / `--Jobs N`	fichiers journaux entiers	plusieurs fichiers journaux indépendants	utile uniquement lorsque suffisamment de fichiers sont disponibles pour garder les workers occupés

Découper un grand fichier avec `-j`

$ pgbadger -j 8 /var/log/postgresql/postgresql.log

L’algorithme upstream divise chaque fichier en plages de N octets, lance un parseur par plage, écrit des statistiques binaires temporaires, puis fusionne ces statistiques pour produire le rapport final.

Imagerie de réplique et amorçage

Mon, 01 Jan 0001 00:00:00 +0000

Patroni permet de personnaliser la création d’une nouvelle réplique. Il prend également en charge la définition des actions à effectuer lors de l’amorçage d’un nouveau cluster vide. La distinction entre les deux est clairement établie : Patroni crée des répliques uniquement si la clé initialize est présente dans le DCS pour le cluster. Si la clé initialize est absente, Patroni lance l’amorçage exclusivement sur le premier nœud qui obtient le verrou de la clé initialize.

Commande d'expiration (expire)

Mon, 01 Jan 0001 00:00:00 +0000

pgBackRest effectue la rotation des sauvegardes complètes selon le type de rétention, qui peut être défini par un nombre ou une période de temps. Lorsqu’un nombre est spécifié, l’expiration n’est pas liée à la date de création des sauvegardes, mais au nombre de sauvegardes à conserver. Les sauvegardes différentielles sont basées sur un nombre, mais sont toujours expirées lorsque la sauvegarde complète dont elles dépendent est expirée. Les sauvegardes incrémentielles ne sont pas expirées indépendamment par rétention — elles sont toujours expirées en même temps que leur sauvegarde complète ou différentielle associée. Pour plus de détails et d’exemples, reportez-vous aux sections Rétention des sauvegardes complètes et Rétention des sauvegardes différentielles .

Fonctionnalités avancées

Mon, 01 Jan 0001 00:00:00 +0000

3.5.1. Fonctionnalités avancées : Gestion

HAProxy est conçu pour rester extrêmement stable et sécurisé à gérer dans un environnement de production classique. Il est fourni sous forme d’un seul fichier exécutable ne nécessitant aucun processus d’installation. Plusieurs versions peuvent coexister facilement, ce qui permet (et est recommandé) de mettre à jour les instances progressivement, par ordre de priorité, plutôt que de les migrer toutes en même temps. Les fichiers de configuration sont facilement versionnés. La vérification de configuration se fait hors ligne, sans nécessiter de redémarrer un service susceptible de échouer. Pendant la vérification de configuration, un certain nombre d’erreurs avancées peuvent être détectées (par exemple, une règle masquant une autre, ou une persistance qui ne fonctionnera pas), et des avertissements détaillés ainsi que des suggestions de configuration sont proposés pour les corriger. La compatibilité des fichiers de configuration avec les versions antérieures s’étend très loin dans le temps : la version 1.5 supporte encore entièrement les configurations écrites pour les versions 1.1, il y a 13 ans, et la version 1.6 n’a abandonné le support que pour des mots-clés presque inutilisés et obsolètes, pouvant être remplacés autrement. Le mécanisme de mise à jour de la configuration et du logiciel est fluide et non disruptif, car il permet à des processus anciens et nouveaux de coexister sur le système, chacun gérant ses propres connexions. L’état du système, les options de compilation et la compatibilité des bibliothèques sont rapportés au démarrage.

Rapports incrémentiels

Mon, 01 Jan 0001 00:00:00 +0000

Le mode incrémentiel stocke les statistiques analysées sous forme binaire, puis génère un rapport HTML par jour, un rapport cumulatif par semaine et un index au format calendrier reliant ces rapports. Il est destiné à un traitement répété des journaux tournés sans compter deux fois les mêmes entrées.

Générer des rapports quotidiens et hebdomadaires

Exécutez pgBadger après la rotation quotidienne des journaux et spécifiez un répertoire de sortie persistant :

Notes de version

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

Les numéros de version de pgBackRest se composent de deux parties : majeure et mineure. Une version majeure peut rompre la compatibilité avec la version majeure précédente, mais les versions v2 sont entièrement compatibles avec les dépôts v1 et acceptent toutes les options v1. Les versions mineures peuvent inclure des correctifs et des fonctionnalités, mais ne modifient pas le format du dépôt et s’efforcent d’éviter tout changement aux options et aux noms. La documentation de la version v1 est disponible ici . Les notes relatives à une version peuvent également contenir des « Notes supplémentaires », mais les modifications dans cette section n’ont d’impact direct que sur la documentation ou le jeu de tests et n’affectent pas le codebase de pgBackRest.

Taille et performance

Mon, 01 Jan 0001 00:00:00 +0000

Les valeurs typiques d’utilisation du processeur montrent que 15 % du temps de traitement sont consacrés à HAProxy contre 85 % au noyau en mode TCP ou HTTP fermé, et environ 30 % pour HAProxy contre 70 % pour le noyau en mode HTTP keep-alive. Cela signifie que le système d’exploitation et son réglage ont une influence forte sur les performances globales.

Questions fréquemment posées

Mon, 01 Jan 0001 00:00:00 +0000

Introduction

Les questions fréquemment posées ont pour but de fournir des précisions sur des questions spécifiques qui peuvent ou non être traitées dans le guide utilisateur, la configuration ou la référence des commandes. Si vous ne trouvez pas de réponse à votre problème particulier ici, n’oubliez pas que la liste des problèmes pgBackRest Issues List in GitHub constitue également une ressource précieuse.

Que faire si j’obtiens l’erreur « impossible de trouver le segment WAL » ?

La cause de cette erreur peut résulter de nombreux problèmes différents, dont certains peuvent être :

Formats de sortie

Mon, 01 Jan 0001 00:00:00 +0000

pgBadger sélectionne la sortie en fonction de l’extension du nom de fichier ou de -x / --extension. Utilisez -o / --outfile plus d’une fois pour générer plusieurs formats à partir du même analyse.

Format	Extension typique	Meilleur usage
HTML	`.html`	rapport interactif, lisible par l’humain avec graphiques
Texte	`.txt`	consultation en terminal et sortie archivée brute
Binaire	`.bin`	statistiques intermédiaires fusionnables et reconstructions de rapport
JSON	`.json`	intégration avec d’autres logiciels ; nécessite `JSON::XS`
CSV brut	fichier de sortie choisi	extraction orientée ligne avec `--dump-raw-csv`

HTML et texte

La sortie par défaut est out.html :

Commande d'aide (help)

Mon, 01 Jan 0001 00:00:00 +0000

Trois niveaux d’aide sont proposés. Si aucune commande n’est spécifiée, une aide générale sera affichée. Si une commande est précisée (par exemple pgbackrest help backup), une description complète de la commande sera affichée, accompagnée d’une liste des options valides. Si une option est précisée en plus d’une commande (par exemple pgbackrest help backup type), une description complète de l’option telle qu’elle s’applique à la commande sera affichée.

Options de commande

Afficher l’option d’aide (`--help`)

Affiche l’aide.

Journal des modifications

Mon, 01 Jan 0001 00:00:00 +0000

PgBouncer 1.25.x

2026-05-08 - PgBouncer 1.25.2 - “Touch humain avec une touche fraîche dans la course au titre pleine d’incertitudes

Sécurité
- Correctif CVE-2026-6664 : Une dépassement d’entier dans le code de traitement des paquets réseau de PgBouncer antérieur à la version 1.25.2 contourne une vérification de borne et peut entraîner un crash. Un attaquant distant non authentifié peut provoquer un crash de PgBouncer en envoyant un paquet d’authentification SCRAM malformé.
- Correctif CVE-2026-6665 : Le code SCRAM de PgBouncer antérieur à la version 1.25.2 ne vérifiait pas correctement la valeur de retour de strlcat() lors de la construction du contenu du message client-final SCRAM. Un serveur malveillant pouvant envoyer un message serveur-final SCRAM avec un nonce long peut déclencher un dépassement de pile.
- Correctif CVE-2026-6666 : Une référence vers un pointeur nul possible dans PgBouncer antérieur à la version 1.25.2 pouvait entraîner un crash si un serveur envoyait une réponse d’erreur sans champ SQLSTATE.
- Correctif CVE-2026-6667 : PgBouncer antérieur à la version 1.25.2 n’effectuait pas de vérification d’autorisation appropriée pour la commande KILL_CLIENT. Tous les utilisateurs ayant accès à la console d’administration, qui nécessite elle-même une authentification, pouvaient exécuter cette commande. Cette opération doit uniquement être autorisée pour les utilisateurs listés dans le paramètre admin_users.
Correctifs

Modes de réplication

Mon, 01 Jan 0001 00:00:00 +0000

Patroni utilise la réplication en streaming de PostgreSQL. Pour en savoir plus sur la réplication en streaming, consultez la documentation Postgres . Par défaut, Patroni configure PostgreSQL pour une réplication asynchrone. Le choix de votre schéma de réplication dépend de vos considérations métier. Étudiez à la fois la réplication asynchrone et synchrone, ainsi que d’autres solutions de haute disponibilité, afin de déterminer la solution la mieux adaptée à votre situation.

cluster de secours

Mon, 01 Jan 0001 00:00:00 +0000

Patroni prend également en charge l’exécution d’une réplication en cascade vers un centre de données distant (région) à l’aide d’une fonctionnalité appelée « stand-by cluster ». Ce type de cluster présente les caractéristiques suivantes :

« leader en veille », qui se comporte presque comme un leader de cluster régulier, à ceci près qu’il effectue la réplication à partir d’un nœud distant.
répliques en cascade, qui effectuent la réplication à partir d’un leader en veille.

Le leader de secours détient et met à jour un verrou de leader dans le DCS. Si le verrou de leader expire, les répliques en cascade effectueront une élection afin de choisir un autre leader parmi les serveurs de secours.

Communauté

Mon, 01 Jan 0001 00:00:00 +0000

Tutoriels

Comment configurer PgBouncer pour Postgres Plus Standard Server

Vue d’ensemble complète des concepts de PgBouncer.

À quoi sert le rebondissement ?

Explique les différences entre les modes de regroupement.

Prise en charge

Info Commande (info)

Mon, 01 Jan 0001 00:00:00 +0000

La commande info s’applique à une seule stanza ou à toutes les stanzas. La sortie texte est la valeur par défaut et fournit un résumé lisible par l’humain des sauvegardes pour la ou les stanzas demandées. Ce format peut évoluer à tout moment dans une version.

Pour une sortie lisible par machine, utilisez --output=json. La sortie JSON contient bien plus d’informations que la sortie texte et est maintenue stable, sauf en cas de bug.

Métriques du projet

Mon, 01 Jan 0001 00:00:00 +0000

Couverture de code

pgBackRest vise à obtenir une couverture complète des fonctions, branches et lignes pour le code C principal dans /src.

La couverture fonctionnelle et par ligne est complète, sans exception.

La couverture de branche exclut les branches à l’intérieur des macros et les appels à assert(). Les macros ont leurs propres tests unitaires, donc elles n’ont pas besoin d’être testées à chaque endroit où elles apparaissent. Les assertions ne doivent pas être complètement couvertes en termes de branche, car elles vérifient des cas qui doivent toujours être vrais.

Rapports d'exemple

Mon, 01 Jan 0001 00:00:00 +0000

Le contenu d’exemple a été généré par pgBadger 11.8 en mai 2022. Les exemples originaux sont stockés avec ce site, de sorte que la navigation dans le rapport, les graphiques, les styles et les scripts restent disponibles sans avoir à interroger le serveur d’origine.

Exemple	Ce qu’il illustre	Copie locale
Rapport complet	Activité PostgreSQL ainsi que les statistiques de PgBouncer	Ouvrir le rapport complet
Rapport incrémentiel	Index calendrier, agrégation hebdomadaire et pages quotidiennes	Ouvrir l’index incrémentiel
Erreurs et événements	Un rapport limité aux erreurs et aux événements opérationnels	Ouvrir le rapport d’erreurs

Rapport complet

Le rapport complet est un document HTML autonome. Utilisez la navigation en haut pour examiner les statistiques globales, les requêtes, les sessions, les connexions, les fichiers temporaires, les points de contrôle, l’activité d’autovacuum, les verrous et les graphiques spécifiques à PgBouncer.

Versions, Paquets et Mises à jour

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est un projet open source soumis à la licence GPLv2, ce qui signifie que toute personne est autorisée à le redistribuer à condition de fournir l’accès au code source sur demande, notamment si des modifications ont été apportées.

HAProxy évolue via une branche de développement principale appelée « master » ou « mainline », à partir de laquelle de nouvelles branches sont créées une fois que le code est jugé stable. De nombreux sites web exécutent des branches de développement en production de manière volontaire, soit pour participer au projet, soit parce qu’ils ont besoin d’une fonctionnalité de pointe, et leurs retours sont précieux pour corriger les bogues et évaluer la qualité et la stabilité globales de la version en développement.

Produits complémentaires et alternatives

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy s’intègre assez bien avec certains produits listés ci-dessous, ce qui justifie leur mention ici, même s’ils ne sont pas directement liés à HAProxy.

4.1. Serveur HTTP Apache

Apache est le serveur HTTP de facto. Il s’agit d’un projet très complet et modulaire, capable de servir des fichiers ainsi que du contenu dynamique. Il peut agir de front-end pour certains serveurs d’applications. Il peut même acheminer des requêtes et mettre en mémoire tampon les réponses. Dans tous ces cas d’utilisation, un répartiteur de charge frontal est généralement nécessaire. Apache peut fonctionner dans divers modes, certains étant plus lourds que d’autres. Certains modules nécessitent encore le modèle pré-forké plus lourd, ce qui empêche Apache de bien évoluer avec un grand nombre de connexions. Dans ce cas, HAProxy peut apporter une aide considérable en imposant des limites de connexion par serveur à une valeur sûre, ce qui accélère significativement le serveur et préserve ses ressources, qui seront mieux utilisées par l’application.

Questions fréquemment posées

Mon, 01 Jan 0001 00:00:00 +0000

Comment se connecter à PgBouncer ?

PgBouncer agit comme un serveur Postgres, il suffit donc de configurer votre client pour qu’il se connecte au port de PgBouncer.

Comment équilibrer la charge des requêtes entre plusieurs serveurs ?

PgBouncer ne dispose pas de configuration interne multi-hôtes. Il est possible via des outils externes :

Round-robin DNS. Utilisez plusieurs adresses IP derrière un même nom DNS. PgBouncer ne résout pas le DNS à chaque nouvelle connexion. Il met en cache toutes les adresses IP et effectue le round-robin de manière interne. Note : si plus de 8 adresses IP sont associées à un même nom, le serveur DNS backend doit prendre en charge le protocole EDNS0. Voir le fichier README pour plus de détails.

Prise en charge du watchdog

Mon, 01 Jan 0001 00:00:00 +0000

L’exécution de plusieurs serveurs PostgreSQL en tant que primaires peut entraîner la perte de transactions en raison de lignes temporelles divergentes. Ce cas est également appelé problème de split-brain. Pour éviter le split-brain, Patroni doit s’assurer que PostgreSQL n’accepte aucune validation de transaction après l’expiration de la clé leader dans le DCS. Dans des conditions normales, Patroni tente d’atteindre cet objectif en arrêtant PostgreSQL lorsque la mise à jour du verrou leader échoue pour quelque raison que ce soit. Toutefois, cette action peut échouer pour diverses raisons :

Commande d'obtention de dépôt (repo-get)

Mon, 01 Jan 0001 00:00:00 +0000

Similaire à la commande unix cat mais fonctionne sur n’importe quel type de dépôt pris en charge. Cette commande nécessite un nom de fichier entièrement qualifié et est principalement destinée à l’administration, l’investigation et les tests. Elle n’est pas obligatoire dans une configuration normale de pgBackRest.

Si le dépôt est chiffré, repo-get déchiffrera automatiquement le fichier. Les fichiers ne sont pas automatiquement décompressés, mais la sortie peut être redirigée vers la commande de décompression appropriée, par exemple gzip -d.

Comment configurer un cluster étcd de démonstration

Mon, 01 Jan 0001 00:00:00 +0000

Sur chaque nœud etcd, précisez les membres du cluster :

TOKEN=token-01
CLUSTER_STATE=new
NAME_1=machine-1
NAME_2=machine-2
NAME_3=machine-3
HOST_1=10.240.0.17
HOST_2=10.240.0.18
HOST_3=10.240.0.19
CLUSTER=${NAME_1}=http://${HOST_1}:2380,${NAME_2}=http://${HOST_2}:2380,${NAME_3}=http://${HOST_3}:2380

Exécutez ceci sur chaque machine :

# For machine 1
THIS_NAME=${NAME_1}
THIS_IP=${HOST_1}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 --listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 --listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} --initial-cluster-token ${TOKEN}

# For machine 2
THIS_NAME=${NAME_2}
THIS_IP=${HOST_2}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 --listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 --listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} --initial-cluster-token ${TOKEN}

# For machine 3
THIS_NAME=${NAME_3}
THIS_IP=${HOST_3}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 --listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 --listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} --initial-cluster-token ${TOKEN}

Ou utilisez notre service de découverte public :

Mode Pause/Reprise pour le cluster

Mon, 01 Jan 0001 00:00:00 +0000

Objectif

Dans certains cas, Patroni doit pouvoir se retirer temporairement de la gestion du cluster tout en conservant l’état du cluster dans le DCS. Les cas d’utilisation possibles concernent des activités inhabituelles sur le cluster, telles que les mises à jour majeures de version ou la récupération après corruption. Pendant ces opérations, les nœuds sont souvent démarrés et arrêtés pour des raisons inconnues de Patroni, certains nœuds pouvant même être temporairement promus, ce qui contrevient à l’hypothèse d’un seul nœud primaire en cours d’exécution. Par conséquent, Patroni doit pouvoir se « déconnecter » du cluster en cours, en implémentant une fonctionnalité équivalente au mode maintenance de Pacemaker.

Prise en charge et contribution

Mon, 01 Jan 0001 00:00:00 +0000

pgBadger est maintenu dans le cadre d’un projet open source. Les rapports de bogues, les propositions de fonctionnalités, les corrections de documentation et les correctifs sont gérés via le dépôt GitHub principal.

Signalements de bogues et demandes de fonctionnalités

Passez à la dernière version publiée et vérifiez que le comportement persiste.
Recherchez dans les problèmes ouverts et les problèmes fermés une réponse existante.
Réduisez le problème à l’échantillon de journal le plus petit possible, qui reproduit encore le comportement.
Supprimez les identifiants, les requêtes SQL sensibles, les valeurs liées, les noms d’hôtes, les adresses et les données métier.
Ouvrez un nouveau problème avec la version de pgBadger, le système d’exploitation, le format d’entrée, les options exactes, le résultat observé et le résultat attendu.

En cas de plantage ou d’erreur de parsing, inclure uniquement les lignes de journalisation minimales et nettoyées nécessaires à la reproduction de la limite. Un journal de production complet ou un rapport généré est rarement adapté à une issue publique.

Commande Liste des dépôts (repo-ls)

Mon, 01 Jan 0001 00:00:00 +0000

Similaire à la commande unix ls mais fonctionne sur tout type de dépôt pris en charge. Cette commande accepte un chemin, absolu ou relatif par rapport au chemin du dépôt défini par l’option --repo-path, et est principalement destinée à l’administration, l’investigation et les tests. Elle n’est pas obligatoire dans une configuration pgBackRest normale.

La sortie texte par défaut affiche un nom de fichier par ligne. La sortie JSON est disponible en spécifiant --output=json.

Documentation et communauté

Mon, 01 Jan 0001 00:00:00 +0000

1. Documentation disponible

La documentation complète de HAProxy est contenue dans les documents suivants. Veuillez vous assurer de consulter la documentation pertinente afin d’économiser du temps et d’obtenir la réponse la plus précise à vos besoins. Veuillez également vous abstenir d’envoyer des questions à la liste de diffusion dont les réponses sont déjà disponibles dans ces documents.

Documentation de configuration

Mon, 01 Jan 0001 00:00:00 +0000

Licence et crédits

Mon, 01 Jan 0001 00:00:00 +0000

pgBadger est un logiciel libre et open source distribué sous la licence PostgreSQL. Il peut être utilisé, copié, modifié et redistribué sans frais, sous réserve du maintien des mentions de copyright et de licence.

Licence PostgreSQL

Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.

Mode de secours DCS

Mon, 01 Jan 0001 00:00:00 +0000

Le problème

Patroni s’appuie fortement sur le magasin de configuration distribué (DCS) pour résoudre les élections de leader et détecter les partitions réseau. Un nœud ne peut exécuter PostgreSQL en tant que primaire que s’il parvient à mettre à jour le verrou de leader dans le DCS. En cas d’échec de mise à jour du verrou de leader, PostgreSQL est immédiatement rétrogradé et lancé en lecture seule. Selon le DCS utilisé, les chances de rencontrer ce problème varient. Par exemple, avec etcd, utilisé exclusivement par Patroni, les chances sont quasi nulles, tandis qu’avec l’API Kubernetes (appuyée sur etcd), ce problème peut être observé plus fréquemment.

Commande de restauration (restore)

Mon, 01 Jan 0001 00:00:00 +0000

La commande de restauration sélectionne automatiquement la dernière sauvegarde du premier dépôt où des sauvegardes existent (voir Démarrage rapide - Restaurer une sauvegarde ). L’ordre dans lequel les dépôts sont vérifiés est déterminé par le pgbackrest.conf (par exemple, repo1 sera vérifié avant repo2). Pour sélectionner un dépôt spécifique, l’option --repo peut être utilisée (par exemple, --repo=1). L’option --set peut être utilisée si une sauvegarde autre que la plus récente est souhaitée.

1. Petit rappel sur HTTP

Mon, 01 Jan 0001 00:00:00 +0000

Ce document traite du langage de configuration tel qu’il est implémenté dans la version indiquée ci-dessus. Il ne fournit aucune indication, exemple ou conseil. Pour ce type de documentation, veuillez vous référer au Manuel de référence ou au Manuel d’architecture. Les chapitres numérotés sont ordonnés dans la barre latérale plate de HAProxy pour une navigation directe.

Lorsque HAProxy fonctionne en mode HTTP, la requête et la réponse sont entièrement analysées et indexées, ce qui permet de définir des critères de correspondance sur presque tout élément présent dans leur contenu.

Commande serveur (server)

Mon, 01 Jan 0001 00:00:00 +0000

Le serveur pgBackRest permet d’accéder aux hôtes distants sans utiliser le protocole SSH.

Options de commande

Option d’adresse serveur TLS (`--tls-server-address`)

Adresse du serveur TLS.

Adresse IP sur laquelle le serveur écoute les requêtes clients.

default: localhost
example: --tls-server-address=*

Option Clients autorisés du serveur TLS (`--tls-server-auth`)

Clients autorisés du serveur TLS.

Utilisation de Patroni avec Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Patroni peut utiliser des objets Kubernetes afin de stocker l’état du cluster et gérer la clé du leader. Cela lui permet de fonctionner avec PostgreSQL dans un environnement Kubernetes sans nécessiter de magasin de cohérence, c’est-à-dire qu’il n’est pas nécessaire de déployer un Étcd supplémentaire. Patroni peut utiliser deux types d’objets Kubernetes pour stocker la clé du leader et les clés de configuration, configurés via les variables d’environnement kubernetes.use_endpoints ou PATRONI_KUBERNETES_USE_ENDPOINTS.

2. Configuration de HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

2.1. Format du fichier de configuration

Le processus de configuration d’HAProxy repose sur 3 sources majeures de paramètres :

les arguments en ligne de commande, qui ont toujours la priorité
le(s) fichier(s) de configuration, dont le format est décrit ici
l’environnement du processus en cours d’exécution, en cas de référence explicite à certaines variables d’environnement

Le fichier de configuration suit un format hiérarchique assez simple qui obéit à quelques règles fondamentales :

Prise en charge Citus

Mon, 01 Jan 0001 00:00:00 +0000

Patroni permet de déployer très facilement des clusters Multi-Node Citus .

TL;DR

Il n’existe que quelques règles simples à suivre :

Extension Citus pour PostgreSQL doit être disponible sur tous les nœuds. La version minimale prise en charge est 10.0, mais pour bénéficier pleinement des basculements planifiés transparents et des redémarrages des workers, nous recommandons d’utiliser au moins la version Citus 11.2.
Le nom du cluster (scope) doit être identique sur tous les nœuds Citus !
Les identifiants de superutilisateur doivent être identiques sur le nœud coordinateur et sur tous les nœuds workers, et pg_hba.conf doit autoriser l’accès en tant que superutilisateur entre tous les nœuds.
API REST doit être accessible depuis les nœuds workers vers le coordinateur. Par exemple, les identifiants doivent être identiques, et si configurés, les certificats clients émis par les nœuds workers doivent être acceptés par le coordinateur.
Ajoutez la section suivante au patroni.yaml :

citus:
 group: X  # 0 for coordinator and 1, 2, 3, etc for workers
 database: citus  # must be the same on all nodes

Ensuite, il vous suffit de démarrer Patroni, qui s’occupera du reste :

Commande de ping serveur (server-ping)

Mon, 01 Jan 0001 00:00:00 +0000

Pongez un serveur TLS pgBackRest pour vérifier qu’il accepte les connexions. Cette opération ne sert qu’à vérifier la disponibilité, car aucune authentification n’est tentée.

Si aucun hôte n’est spécifié en ligne de commande, l’option tls-server-host sera utilisée.

Options de commande

Option d’adresse serveur TLS (`--tls-server-address`)

Adresse du serveur TLS.

Adresse IP sur laquelle le serveur écoute les requêtes clients.

default: localhost
example: --tls-server-address=*

Option de port serveur TLS (`--tls-server-port`)

Port du serveur TLS.

3. Section globale

Mon, 01 Jan 0001 00:00:00 +0000

Les paramètres de la section « global » sont applicables à l’ensemble du processus et souvent spécifiques au système d’exploitation. Ils sont généralement définis une fois pour toutes et n’exigent pas de modification une fois correctement configurés. Certains d’entre eux ont des équivalents en ligne de commande.

Les mots-clés suivants sont pris en charge dans la section « global » :

Gestion des processus et sécurité

Convertir un nœud autonome en cluster Patroni

Mon, 01 Jan 0001 00:00:00 +0000

Cette section décrit le processus de conversion d’une instance PostgreSQL autonome en cluster Patroni.

Pour déployer un cluster Patroni sans utiliser d’instance PostgreSQL préexistante, consultez plutôt Exécution et configuration .

Procédure

Vous trouverez ci-dessous un aperçu des étapes permettant de convertir un cluster Postgres existant en cluster géré par Patroni. Dans ces étapes, nous supposons que tous les nœuds faisant partie du cluster existant sont actuellement en fonctionnement, et que vous ne prévoyez pas de modifier la configuration de Postgres pendant la migration. Les étapes :

Commande de création de stanza (stanza-create)

Mon, 01 Jan 0001 00:00:00 +0000

La commande stanza-create doit être exécutée après la configuration du stanza dans pgbackrest.conf. Si plusieurs dépôts sont configurés, le stanza sera créé sur chacun d’eux. Les stanzas déjà créés seront ignorés, ce qui rend toujours sûr l’exécution de stanza-create, même après la configuration d’un nouveau dépôt.

Consultez Créer une stanza pour plus d’informations et un exemple.

Options de commande

Option en ligne (`--online`)

Créez sur un cluster en ligne.

4. Proxies

Mon, 01 Jan 0001 00:00:00 +0000

La configuration du proxy peut être située dans un ensemble de sections :

defaults [<name>] [ depuis <defaults_name> ]
frontal <name> [ depuis <defaults_name> ]
backend <name> [ depuis <defaults_name> ]
écouter <name> [ depuis <defaults_name> ]

Une section « frontend » décrit un ensemble de sockets d’écoute acceptant les connexions clientes.

Une section « backend » décrit un ensemble de serveurs auxquels le proxy se connectera pour acheminer les connexions entrantes.

Intégration avec d'autres outils

Mon, 01 Jan 0001 00:00:00 +0000

Patroni est capable d’intégrer d’autres outils de votre infrastructure. Dans cette section, vous trouverez une liste d’exemples, qui, bien qu’elle ne soit pas exhaustive, peut vous inspirer sur les façons dont Patroni peut s’intégrer à d’autres outils.

Barman

Patroni fournit une application nommée patroni_barman qui intègre la logique de communication avec pg-backup-api, vous permettant ainsi d’effectuer des opérations Barman à distance.

Cette application possède actuellement plusieurs sous-commandes : recover et config-switch.

Commande de suppression de stanza (stanza-delete)

Mon, 01 Jan 0001 00:00:00 +0000

La commande stanza-delete supprime les données du dépôt associées à un stanza.

AVERTISSEMENT :

Utilisez cette commande avec précaution — elle supprimera définitivement toutes les sauvegardes et archives du dépôt pgBackRest pour le stanza spécifié.

Pour supprimer une stanza :

Arrêtez le cluster PostgreSQL associé à la stanza (ou utilisez –force pour l’ignorer).
Exécutez la commande stop sur l’hôte où la commande stanza-delete sera exécutée.
Exécutez la commande stanza-delete.

Une fois la commande exécutée avec succès, il incombe à l’utilisateur de supprimer la stanza de tous les fichiers de configuration pgBackRest et/ou des variables d’environnement.

5. Options de liaison et de serveur

Mon, 01 Jan 0001 00:00:00 +0000

Les mots-clés « bind », « server » et « default-server » prennent en charge un certain nombre de paramètres, selon certains options de compilation et le système sur lequel HAProxy a été compilé. Ces paramètres sont généralement composés d’un mot, parfois suivi d’une valeur, écrits sur la même ligne que la directive « bind » ou « server ». Tous ces paramètres sont décrits dans cette section.

Considérations de sécurité

Mon, 01 Jan 0001 00:00:00 +0000

Un cluster Patroni dispose de deux interfaces à protéger contre l’accès non autorisé : le stockage de configuration distribué (DCS) et l’API REST Patroni.

Protection du SCD

Patroni et patronictl stockent et récupèrent des données auprès du DCS.

Bien que le DCS ne contienne aucune information sensible, il permet de modifier certaines configurations de Patroni/PostgreSQL. Par conséquent, la première mesure à prendre est de protéger le DCS lui-même.

Commande de mise à jour de stanza (stanza-upgrade)

Mon, 01 Jan 0001 00:00:00 +0000

Immédiatement après la mise à niveau de PostgreSQL vers une nouvelle version majeure, le pg-path de toutes les configurations pgBackRest doit être défini sur le nouveau emplacement de la base de données, puis la commande stanza-upgrade doit être exécutée. Si plusieurs dépôts sont configurés sur l’hôte, le stanza sera mis à niveau sur chacun. Si la base de données est hors ligne, utilisez l’option --no-online.

Options de commande

Option en ligne (`--online`)

Mettre à jour un cluster en ligne.

6. Mise en cache

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy fournit un cache, conçu pour effectuer le mise en mémoire tampon de petits objets (favicon, fichiers CSS…). Il s’agit d’un cache minimaliste, à faible maintenance, qui s’exécute en mémoire RAM.

Le cache repose sur une zone mémoire partagée entre tous les threads, divisée en blocs de 1 ko.

Si un objet n’est plus utilisé, il peut être supprimé afin de stocker un nouvel objet indépendamment de sa date d’expiration. Les objets les plus anciens sont supprimés en premier lorsque l’on tente d’allouer un nouvel objet.

Haute disponibilité multi-centre de données

Mon, 01 Jan 0001 00:00:00 +0000

La haute disponibilité d’un cluster PostgreSQL déployé dans plusieurs centres de données repose sur la réplication, qui peut être synchrone ou asynchrone (voir modes de réplication ).

Dans les deux cas, il est important de bien comprendre les concepts suivants :

PostgreSQL peut fonctionner en tant que leader primaire ou en mode standby uniquement lorsqu’il détient la clé de leadership et peut mettre à jour cette clé.
Vous devez exécuter un nombre impair de nœuds etcd, ZooKeeper ou Consul : 3 ou 5 !

Réplication synchrone

Pour disposer d’un cluster multi-DC pouvant tolérer automatiquement la perte d’une zone, un minimum de 3 est requis.

Commande de démarrage (start)

Mon, 01 Jan 0001 00:00:00 +0000

Si les processus pgBackRest ont été précédemment arrêtés à l’aide de la commande stop, ils peuvent être redémarrés à l’aide de la commande start. Notez qu’il ne s’agit pas d’un démarrage immédiat des processus pgBackRest, mais qu’ils sont autorisés à s’exécuter. Voir Démarrage et arrêt pour plus d’informations et d’exemples.

Options générales

Autoriser l’exécution en tant qu’utilisateur root (`--allow-root`)

Permettre à la commande de s’exécuter en tant qu’utilisateur root.

7. Listes de contrôle d'accès et extraction d'échantillon

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est capable d’extraire des données des flux de requêtes ou de réponses, des informations client ou serveur, des tables, des informations environnementales, etc. L’opération d’extraction de ces données est appelée « récupération d’un échantillon ». Une fois récupérés, ces échantillons peuvent être utilisés à diverses fins, par exemple comme clé dans une table de persistance, mais les usages les plus courants consistent à les comparer à des données constantes prédéfinies appelées modèles.

FAQ

Mon, 01 Jan 0001 00:00:00 +0000

Dans cette section, vous trouverez les réponses aux questions les plus fréquemment posées concernant Patroni. Chaque sous-section s’efforce de se concentrer sur des types de questions différents.

Nous espérons que cela vous aidera à clarifier la majeure partie de vos questions. Si vous avez encore des interrogations ou rencontrez un problème imprévu, veuillez vous référer à chatting et reporting_bugs pour obtenir des instructions sur la manière de demander de l’aide ou de signaler des anomalies.

Commande d'arrêt (stop)

Mon, 01 Jan 0001 00:00:00 +0000

N’autorise aucun nouveau processus pgBackRest à s’exécuter. Par défaut, les processus en cours d’exécution sont autorisés à se terminer correctement. Utilisez l’option --force pour terminer les processus en cours.

Les processus pgBackRest retourneront une erreur s’ils sont exécutés après la fin de la commande d’arrêt. Consultez Démarrage et arrêt pour plus d’informations et d’exemples.

Options de commande

Option obligatoire (`--force`)

Forcer l’arrêt de tous les processus pgBackRest.

8. Journalisation

Mon, 01 Jan 0001 00:00:00 +0000

L’un des points forts d’HAProxy réside certainement dans ses journaux précis. Il fournit probablement le niveau d’information le plus poussé disponible pour un tel produit, ce qui est essentiel pour le dépannage des environnements complexes. Les informations standard fournies dans les journaux incluent les ports clients, les compteurs d’état TCP/HTTP, l’état précis du flux à la terminaison et la cause précise de la terminaison, des informations sur les décisions visant à acheminer le trafic vers un serveur, ainsi que, bien entendu, la capacité à capturer des en-têtes arbitraires.

Notes de version

Mon, 01 Jan 0001 00:00:00 +0000

Version 4.1.5

Libéré le 2026-08-12

Améliorations de compatibilité

Compatibilité avec PostgreSQL 14.24, 15.19, 16.15, 17.11, 18.6 (Alexander Kukushkin)

Ajoutez le nouveau paramètre GUC output_plugin_libraries, qui restreint les plugins de décodage logique.

Améliorations

Réinitialisations de connexion de l’API REST à DEBUG au lieu de WARNING (Kyle McLaren)

Assurez-vous que les variantes courantes de « client est parti au milieu de l’écriture » sont désactivées sans affecter le traitement des erreurs réelles (non liées à la connexion).

Commande de vérification (verify)

Mon, 01 Jan 0001 00:00:00 +0000

Verify détermine si les sauvegardes et les archives présentes dans un dépôt sont valides.

Options de commande

Option de sortie (`--output`)

Type de sortie.

Les types de sortie suivants sont pris en charge :

none - Aucune vérification de sortie.
text - Informations de vérification de sortie affichées sur stdout.

default: none
example: --output=text

Définir l’option (`--set`)

Sauvegarde configurée pour vérification.

9. Filtres pris en charge

Mon, 01 Jan 0001 00:00:00 +0000

Voici la liste des filtres officiellement pris en charge, accompagnée de la liste des paramètres qu’ils acceptent. En fonction des options de compilation, certains de ces filtres pourraient être indisponibles. La liste des filtres disponibles est indiquée dans HAProxy -vv.

Voir aussi : « filter »

9.1. Trace

filtre trace [nom <name>] [redirection aléatoire] [nombre maximal de redirections <max>] [affichage hexadécimal]

Guidelines pour les contributions

Mon, 01 Jan 0001 00:00:00 +0000

Discussion

Si vous avez une question, recherchez une aide interactive pour dépanner ou souhaitez discuter avec d’autres utilisateurs Patroni, rejoignez-nous sur le canal #patroni dans PostgreSQL Slack .

Signalement de bogues

Avant de signaler un bogue, assurez-vous d’en reproduire l’incident avec la dernière version de Patroni ! Veuillez également vérifier soigneusement si le problème n’existe pas déjà dans notre Suivi des problèmes .

Lecture depuis etcd

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Installer etcdctl

Procédure

Utilisez la sous-commande get pour lire depuis etcd :

$ etcdctl --endpoints=$ENDPOINTS get foo
foo
Hello World!
$

où :

foo est la clé demandée
Hello World! est la valeur récupérée

Or, pour une sortie formatée :

$ etcdctl --endpoints=$ENDPOINTS --write-out="json" get foo
{"header":{"cluster_id":289318470931837780,"member_id":14947050114012957595,"revision":3,"raft_term":4,
"kvs":[{"key":"Zm9v","create_revision":2,"mod_revision":3,"version":2,"value":"SGVsbG8gV29ybGQh"}]}}
$

où write-out="json" fait que la valeur est sortie au format JSON (notez que la clé n’est pas renvoyée).

Commande Version (version)

Mon, 01 Jan 0001 00:00:00 +0000

Affiche la version de pgBackRest installée.

Options de commande

Option de sortie (`--output`)

Type de sortie.

Les types de sortie suivants sont pris en charge :

text - Affiche la version installée de pgBackRest sous forme de texte.
num - Affiche la version installée de pgBackRest sous forme d’entier.

default: text
example: --output=num

10. Applications FastCGI

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est capable d’envoyer des requêtes HTTP vers des applications FastCGI Responder. Cette fonctionnalité a été ajoutée à HAProxy 2.1. Pour cela, les serveurs doivent être configurés pour utiliser le protocole FastCGI (en utilisant le mot-clé « proto fcgi » dans la ligne du serveur) et une application FastCGI doit être configurée et utilisée par le backend gérant ces serveurs (en utilisant le mot-clé « use-fcgi-app » dans la section proxy). Plusieurs applications FastCGI peuvent être définies, mais un seul peut être utilisé à la fois par un backend.

11. Tables de persistance et pairs

Mon, 01 Jan 0001 00:00:00 +0000

Les tables de persistance dans HAProxy sont un mécanisme qui permet d’associer un certain nombre d’informations et de métriques à une clé d’un type donné, pendant une durée déterminée après la dernière mise à jour. Cela peut être vu comme une ligne à plusieurs colonnes dans un tableau, où le numéro de ligne est défini par la valeur de la clé, et chaque colonne représente un critère distinct.

12. Autres sections

Mon, 01 Jan 0001 00:00:00 +0000

Les sections décrites ci-dessous sont moins couramment utilisées et ne prennent généralement en charge qu’un petit nombre de paramètres. Il n’existe aucune relation implicite entre elles. Elles sont toutes initiales à l’aide d’un mot-clé unique. Aucune d’entre elles n’est autorisée avant une section « global ». Le support de certaines d’entre elles peut être conditionné par des options de compilation (par exemple, tout ce qui est lié au SSL).

Guide de gestion

Mon, 01 Jan 0001 00:00:00 +0000

1. Prérequis

Mon, 01 Jan 0001 00:00:00 +0000

Ce document décrit comment démarrer, arrêter, gérer et dépanner HAProxy, ainsi que certaines limitations connues et pièges à éviter. Il ne décrit pas comment le configurer (pour cela, veuillez consulter configuration.txt ).

Dans ce document, il est supposé que le lecteur possède des compétences suffisantes en administration sur un système d’exploitation de type UNIX, utilise quotidiennement l’interpréteur de commandes et maîtrise les outils de dépannage tels que strace et tcpdump.

Écriture dans etcd

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Installer etcdctl

Procédure

Utilisez la sous-commande put pour écrire une paire clé-valeur :

etcdctl --endpoints=$ENDPOINTS put foo "Hello World!"

où :

foo est le nom de la clé
"Hello World!" est la valeur délimitée par des guillemets

2. HAProxy Architecture

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est un démon multithreadé, basé sur des événements et non bloquant. Cela signifie qu’il utilise la multiplexion d’événements pour planifier toutes ses activités, plutôt que de dépendre du système pour planifier entre plusieurs activités. La plupart du temps, il s’exécute sous la forme d’un seul processus, de sorte que la sortie de la commande « ps aux » sur un système ne répertorie qu’un seul processus « HAProxy », sauf en cas de rechargement doux en cours, auquel cas un processus ancien peut encore s’exécuter en parallèle du nouveau. Il est donc toujours facile de suivre son activité à l’aide de l’outil strace. Pour s’adapter au nombre de processeurs disponibles, HAProxy démarre, par défaut, un thread worker par processeur sur lequel il est autorisé à s’exécuter. À moins d’être configuré autrement, le trafic entrant est réparti entre tous ces threads, chacun exécutant la même boucle d’événements. Une grande attention est portée à limiter les dépendances entre threads au strict minimum, afin de tenter d’obtenir une scalabilité quasi linéaire. Cela a certaines conséquences, notamment le fait qu’une connexion donnée soit servie par un seul thread. Ainsi, pour utiliser toute la capacité de traitement disponible, il faut disposer d’au moins autant de connexions que de threads, ce qui est presque toujours le cas.

3. Démarrage de HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est lancé en exécutant le programme « HAProxy » avec un certain nombre d’arguments passés en ligne de commande. La syntaxe réelle est :

$ haproxy [<options>]*

où [<options>]* est un nombre quelconque d’options. Une option commence toujours par ‘-’ suivi d’une ou plusieurs lettres, et peut être suivie d’un ou plusieurs arguments supplémentaires. Sans option, HAProxy affiche la page d’aide avec un rappel des options prises en charge. Les options disponibles peuvent varier légèrement selon le système d’exploitation. Un nombre important de ces options se chevauchent avec une option équivalente dans la section « global ». Dans ce cas, la ligne de commande a toujours priorité sur le fichier de configuration, de sorte que la ligne de commande peut être utilisée pour imposer rapidement certains paramètres sans modifier les fichiers de configuration. La liste actuelle des options est :

4. Arrêt et redémarrage de HAProxy

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy prend en charge une interruption douce et une interruption brutale. L’interruption brutale est simple : lorsqu’un signal SIGTERM est envoyé au processus HAProxy, celui-ci quitte immédiatement et toutes les connexions établies sont fermées. L’interruption douce est déclenchée lorsqu’un signal SIGUSR1 est envoyé au processus HAProxy. Elle consiste à ne plus se lier aux ports d’écoute, tout en continuant à traiter les connexions existantes jusqu’à leur fermeture. Une fois la dernière connexion fermée, le processus se termine.

5. Limites des descripteurs de fichiers

Mon, 01 Jan 0001 00:00:00 +0000

Afin de garantir que toutes les connexions entrantes soient correctement servies, HAProxy calcule au moment du chargement le nombre total de descripteurs de fichiers nécessaires durant la durée de vie du processus. Un processus Unix classique reçoit généralement 1024 descripteurs de fichiers par défaut, et un processus privilégié peut augmenter lui-même cette limite. C’est une des raisons de lancer HAProxy en tant que root et de lui permettre d’ajuster cette limite. La limite par défaut de 1024 descripteurs de fichiers permet approximativement 500 connexions simultanées. Ce calcul repose sur le paramètre global maxconn, qui limite le nombre total de connexions par processus, le nombre d’écouteurs, le nombre de serveurs ayant un contrôle d’état activé, les vérifications d’agent, les pairs, les enregistreurs et éventuellement quelques autres exigences techniques. Une estimation simple de ce nombre consiste à doubler la valeur de maxconn et à ajouter quelques dizaines pour obtenir une approximation du nombre de descripteurs de fichiers nécessaires.

6. Gestion de la mémoire

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy utilise une gestion mémoire basée sur des pools, simple et rapide. Étant donné qu’il repose sur un nombre réduit de types d’objets différents, il est bien plus efficace de tirer de nouveaux objets depuis un pool déjà contenant des objets de la taille appropriée que d’appeler malloc() pour chaque taille différente. Les pools sont organisés selon une structure de pile ou LIFO, de sorte que les objets nouvellement alloués proviennent d’objets récemment libérés, encore présents dans les caches CPU. Les pools de tailles similaires sont regroupés afin de limiter la fragmentation mémoire.

Comment obtenir des clés par préfixe

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Obtenir les clés par préfixe

$ etcdctl --endpoints=$ENDPOINTS get PREFIX --prefix

Options globales

--endpoints=[127.0.0.1:2379], gRPC endpoints

Options

--prefix, get a range of keys with matching prefix

Exemple

etcdctl --endpoints=$ENDPOINTS put web1 value1
etcdctl --endpoints=$ENDPOINTS put web2 value2
etcdctl --endpoints=$ENDPOINTS put web3 value3

etcdctl --endpoints=$ENDPOINTS get web --prefix

7. Utilisation du CPU

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy passe normalement la majeure partie de son temps en mode noyau et une part plus faible en mode utilisateur. Un processeur 3,5 GHz correctement optimisé peut supporter un débit d’environ 80 000 établissements et fermetures de connexions bout-en-bout par seconde à 100 % d’utilisation sur un seul cœur. Lorsqu’un cœur est saturé, les valeurs typiques sont :

95 % système, 5 % utilisateur pour des connexions TCP longues ou de grands objets HTTP
85 % système et 15 % utilisateur pour des connexions TCP courtes ou de petits objets HTTP en mode fermé
70 % système et 30 % utilisateur pour de petits objets HTTP en mode keep-alive

Le nombre de règles traitées et d’expressions régulières augmente la partie en espace utilisateur. La présence de règles de pare-feu, du suivi des connexions et de tables de routage complexes dans le système augmente quant à elle la partie noyau.

8. Journalisation

Mon, 01 Jan 0001 00:00:00 +0000

Pour la journalisation, HAProxy s’appuie toujours sur un serveur syslog, car il ne réalise aucune opération sur le système de fichiers. La méthode standard consiste à envoyer les journaux via UDP vers le serveur de journalisation (par défaut sur le port 514). Il est très courant de le configurer sur 127.0.0.1, où s’exécute le démon syslog local, mais il peut aussi être utilisé sur le réseau pour journaliser sur un serveur central. Ce dernier offre des avantages supplémentaires, notamment dans les scénarios actif-actif où il est souhaitable de conserver les journaux fusionnés dans l’ordre d’arrivée. HAProxy peut également utiliser une socket UNIX pour envoyer ses journaux au démon syslog local, mais cela n’est pas recommandé, car si le serveur syslog est redémarré pendant que HAProxy est en cours d’exécution, la socket sera remplacée et les nouveaux journaux seront perdus. Étant donné que HAProxy sera isolé dans une prison chroot, il ne pourra pas se reconnecter à la nouvelle socket. Des observations sur le terrain ont également montré que les tampons utilisés sur les sockets UNIX sont très petits et entraînent la perte de messages même à des charges très faibles. Cela peut toutefois convenir pour les tests.

9. Statistiques et surveillance

Mon, 01 Jan 0001 00:00:00 +0000

Il est possible de consulter l’état de HAProxy. Le mécanisme le plus couramment utilisé est la page de statistiques HTTP. Cette page expose également un format de sortie CSV alternatif destiné aux outils de surveillance. Le même format est disponible via le socket Unix.

Les statistiques sont regroupées par catégories désignées sous le nom de domaines, correspondant aux différents composants d’HAProxy. Deux domaines sont disponibles : proxy et resolvers. Si aucun domaine n’est précisé, le domaine proxy est sélectionné. Notez que seules les statistiques du proxy sont affichées sur la page HTTP.

10. Gestion de configuration simplifiée

Mon, 01 Jan 0001 00:00:00 +0000

Il est très courant que deux nœuds HAProxy constituant un cluster partagent exactement la même configuration, à l’exception de quelques adresses. Au lieu de devoir maintenir une configuration dupliquée pour chaque nœud, ce qui entraînera inévitablement une divergence, il est possible d’inclure des variables d’environnement dans la configuration. Ainsi, plusieurs configurations peuvent partager exactement le même fichier, en ne modifiant que quelques variables d’environnement système. Cette fonctionnalité a été introduite à partir de la version 1.5, où seules les adresses pouvaient inclure des variables d’environnement, et la version 1.6 va plus loin en permettant l’utilisation de variables d’environnement partout. La syntaxe est identique à celle du shell UNIX : une variable commence par un signe dollar (’$’), suivi d’une accolade ouvrante (’{’), puis le nom de la variable, terminé par une accolade fermante (’}’). À l’exception des adresses, les variables d’environnement ne sont interprétées que dans les arguments entourés de guillemets doubles (ce qui était nécessaire pour ne pas rompre les configurations existantes utilisant des expressions régulières impliquant le symbole dollar).

11. Pièges courants à éviter

Mon, 01 Jan 0001 00:00:00 +0000

Parfois, une personne signale que, après un redémarrage du système, le service HAProxy n’est pas démarré automatiquement, et qu’une fois lancé manuellement, il fonctionne correctement. La plupart de ces utilisateurs exécutent un mécanisme d’adresse IP regroupée, comme keepalived, afin d’attribuer l’adresse IP du service uniquement au nœud principal, et alors qu’il fonctionnait auparavant lorsqu’ils liaient HAProxy à l’adresse 0.0.0.0, il a cessé de fonctionner après avoir lié celui-ci à l’adresse IP virtuelle. Ce qui se produit ici, c’est que, lors du démarrage du service, l’adresse IP virtuelle n’est pas encore détenu par le nœud local, si bien que lorsque HAProxy tente de se lier à cette adresse, le système la rejette car elle n’est pas une adresse locale. La solution ne consiste pas à retarder le démarrage du service HAProxy (car cela ne résisterait pas à un redémarrage), mais plutôt à configurer correctement le système afin de permettre la liaison à des adresses non locales. Cela peut être facilement réalisé sous Linux en définissant le paramètre sysctl net.ipv4.ip_nonlocal_bind à 1. Cette configuration est également nécessaire pour intercepter de manière transparente le trafic IP qui traverse HAProxy pour une adresse cible spécifique.

12. Problèmes de débogage et de performance

Mon, 01 Jan 0001 00:00:00 +0000

Lorsque HAProxy est lancé avec l’option “-d”, il reste en premier plan et affiche une ligne par événement, tel qu’une connexion entrante, la fin d’une connexion, ou chaque ligne d’en-tête de requête ou de réponse observée. Cette sortie de débogage est émise avant le traitement des contenus, aussi ne tiennent-elles pas compte des modifications locales. Son usage principal consiste à afficher les requêtes et réponses sans avoir à exécuter un analyseur réseau. La lecture de la sortie devient moins aisée lorsque plusieurs connexions sont gérées en parallèle, mais les scripts “debug2ansi” et “debug2html” présents dans le répertoire examples/ aident certainement dans ce cas en colorant la sortie.

13. Considérations de sécurité

Mon, 01 Jan 0001 00:00:00 +0000

HAProxy est conçu pour s’exécuter avec des privilèges très limités. La méthode standard consiste à l’isoler dans une prison chroot et à supprimer ses privilèges pour qu’il s’exécute en tant qu’utilisateur non root, sans aucun droit à l’intérieur de cette prison, afin qu’en cas de découverte d’une vulnérabilité future, son compromis n’affecte pas le reste du système.

Pour effectuer un chroot, il est d’abord nécessaire de le lancer en tant qu’utilisateur root. Il est inutile de créer manuellement des chroots afin de lancer le processus à l’intérieur ; ces environnements sont difficiles à mettre en place, jamais correctement maintenus et contiennent toujours bien plus de bogues que le système de fichiers principal. En cas de compromission, l’attaquant peut exploiter le système de fichiers spécifiquement conçu à cet effet. Malheureusement, de nombreux administrateurs confondent « lancer en tant que root » et « s’exécuter en tant que root », ce qui entraîne le changement d’UID avant le démarrage d’HAProxy, réduisant ainsi les restrictions de sécurité effectives.

Comment supprimer des clés

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Installer etcd et etcdctl

Ajouter ou supprimer des clés

del pour supprimer la clé spécifiée ou la plage de clés :

etcdctl del $KEY [$END_KEY]

Options

--prefix[=false]: delete keys with matching prefix
--prev-kv[=false]: return deleted key-value pairs
--from-key[=false]: delete keys that are greater than or equal to the given key using byte compare
--range[=false]: delete range of keys without delay

Options héritées des commandes parentes

--endpoints="127.0.0.1:2379": gRPC endpoints

Exemples

etcdctl --endpoints=$ENDPOINTS put key myvalue
etcdctl --endpoints=$ENDPOINTS del key

etcdctl --endpoints=$ENDPOINTS put k1 value1
etcdctl --endpoints=$ENDPOINTS put k2 value2
etcdctl --endpoints=$ENDPOINTS del k --prefix

Comment effectuer plusieurs écritures dans une transaction

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Installer etcd et etcdctl .
Un cluster etcd en cours d’exécution.

Terminologie

Voici les définitions de quelques termes clés utilisés dans l’exemple Example ci-dessous.

Termes	Définition
etcdctl	Outil en ligne de commande pour interagir avec le serveur etcd.
`txn` command	`txn` command est une abréviation de « transaction ». Il lit plusieurs requêtes etcd depuis l’entrée standard et les applique comme une transaction atomique unique. Une transaction se compose d’une liste de conditions, d’une liste de requêtes à appliquer si toutes les conditions sont vraies, et d’une liste de requêtes à appliquer si au moins une condition est fausse. Consultez etcdctl key-value commands pour plus d’informations.
`compare`	La clause `compare` au sein d’une transaction (`txn`) sert de vérification conditionnelle déterminant si les opérations de la transaction doivent s’exécuter. Elle garantit que les modifications ne sont appliquées que si l’état actuel du magasin clé-valeur correspond aux conditions attendues, assurant ainsi la cohérence des données et évitant les conflits dans les environnements concurrents. Pour voir la structure de la commande, consultez la section Effectuer une transaction ci-dessous.

Transactions

txn pour traiter toutes les requêtes dans une seule transaction :

Comment surveiller des clés

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Installer etcd et etcdctl

Surveillance des clés

watch pour être notifié des modifications futures :

etcdctl watch $KEY [$END_KEY]

Options

-i, --interactive[=false]: interactive mode
--prefix[=false]: watch on a prefix if prefix is set
--rev=0: Revision to start watching
--prev-kv[=false]: get the previous key-value pair before the event happens
--progress-notify[=false]: get periodic watch progress notification from server

Options héritées des commandes parentes

--endpoints="127.0.0.1:2379": gRPC endpoints

Exemples

etcdctl --endpoints=$ENDPOINTS watch stock1
etcdctl --endpoints=$ENDPOINTS put stock1 1000

etcdctl --endpoints=$ENDPOINTS watch stock --prefix
etcdctl --endpoints=$ENDPOINTS put stock1 10
etcdctl --endpoints=$ENDPOINTS put stock2 20

Comment créer un bail

Mon, 01 Jan 0001 00:00:00 +0000

lease pour écrire avec un TTL :

etcdctl --endpoints=$ENDPOINTS lease grant 300
# lease 2be7547fbc6a5afa granted with TTL(300s)

etcdctl --endpoints=$ENDPOINTS put sample value --lease=2be7547fbc6a5afa
etcdctl --endpoints=$ENDPOINTS get sample

etcdctl --endpoints=$ENDPOINTS lease keep-alive 2be7547fbc6a5afa
etcdctl --endpoints=$ENDPOINTS lease revoke 2be7547fbc6a5afa
# or after 300 seconds
etcdctl --endpoints=$ENDPOINTS get sample

Comment créer des verrous

Mon, 01 Jan 0001 00:00:00 +0000

LOCK acquiert un verrou distribué portant un nom donné. Une fois le verrou acquis, il reste détenu jusqu’à la terminaison d’etcdctl.

Prérequis

Installer etcd et etcdctl

Création d’un verrou

lock pour verrouillage distribué :

etcdctl --endpoints=$ENDPOINTS lock mutex1

Options

endpoints - définit une liste séparée par des virgules d’adresses machine du cluster.
ttl - durée d’expiration en secondes de la session de verrouillage.

Comment effectuer l'élection du leader dans un cluster etcd

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Vérifiez que etcd et etcdctl sont installés.
Vérifiez l’état du cluster etcd actif.

Conduire l’élection du leader

La commande etcdctl est utilisée pour effectuer des élections de leader dans un cluster etcd. Elle garantit qu’un seul client peut devenir leader à la fois.

etcdctl --endpoints=$ENDPOINTS elect <election-name> [proposal]

etcdctl --endpoints=$ENDPOINTS elect election-name p1

Options

--endpoints : $ENDPOINTS

Adresse de chaque membre du cluster etcd.

Démarrage rapide

Mon, 01 Jan 0001 00:00:00 +0000

Suivez ces instructions pour installer, exécuter et tester localement un cluster à membre unique de etcd :

Installez etcd à partir de binaires précompilés ou du code source. Pour plus de détails, consultez Installation .

Avertissement

Important : Veillez à effectuer la dernière étape des instructions d’installation afin de vérifier que etcd est dans votre chemin.
Démarrer etcd :
```
$ etcd
{"level":"info","ts":"2021-09-17T09:19:32.783-0400","caller":"etcdmain/etcd.go:72","msg":... }
⋮
```
Note

Remarque : La sortie produite par etcd est logs — des journaux de niveau info peuvent être ignorés.

Comment vérifier l'état du cluster

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Installer etcd et etcdctl

Vérifier l’état global

endpoint status pour vérifier l’état global de chaque point de terminaison spécifié dans le drapeau --endpoints :

etcdctl endpoint status (--endpoints=$ENDPOINTS|--cluster)

Options

--cluster[=false]: use all endpoints from the cluster member list

Vérifier l’état de santé

endpoint health pour vérifier l’état de santé de chaque point de terminaison spécifié dans le drapeau --endpoints :

Comment sauvegarder la base de données

Mon, 01 Jan 0001 00:00:00 +0000

Prérequis

Effectuer un instantané d’une base de données

snapshot pour sauvegarder un instantané du stockage etcd à un instant donné :

etcdctl --endpoints=$ENDPOINT snapshot save DB_NAME

Options globales

etcdctl

--endpoints=[127.0.0.1:2379], gRPC endpoints

Un instantané ne peut être demandé qu’à un nœud etcd, donc le drapeau --endpoints ne doit contenir qu’un seul point de terminaison.

Exemple

Mon, 01 Jan 0001 00:00:00 +0000

Cette série d’exemples illustre les procédures de base pour travailler avec un cluster etcd.

Auth

auth,user,role pour l’authentification :

export ETCDCTL_API=3
ENDPOINTS=localhost:2379

etcdctl --endpoints=${ENDPOINTS} role add root
etcdctl --endpoints=${ENDPOINTS} role get root

etcdctl --endpoints=${ENDPOINTS} user add root
etcdctl --endpoints=${ENDPOINTS} user grant-role root root
etcdctl --endpoints=${ENDPOINTS} user get root

etcdctl --endpoints=${ENDPOINTS} role add role0
etcdctl --endpoints=${ENDPOINTS} role grant-permission role0 readwrite foo
etcdctl --endpoints=${ENDPOINTS} user add user0
etcdctl --endpoints=${ENDPOINTS} user grant-role user0 role0

etcdctl --endpoints=${ENDPOINTS} auth enable
# now all client requests go through auth

etcdctl --endpoints=${ENDPOINTS} --user=user0:123 put foo bar
etcdctl --endpoints=${ENDPOINTS} get foo
# permission denied, user name is empty because the request does not issue an authentication request
etcdctl --endpoints=${ENDPOINTS} --user=user0:123 get foo
# user0 can read the key foo
etcdctl --endpoints=${ENDPOINTS} --user=user0:123 get foo1

Installer

Mon, 01 Jan 0001 00:00:00 +0000

Exigences

Avant d’installer etcd, consultez les pages suivantes :

[Plateformes prises en charge][]
[Recommandations matérielles][]

Installer les binaires préconstruits

La méthode la plus simple pour installer etcd consiste à utiliser des binaires pré-construits :

Téléchargez le fichier archive compressé pour votre plateforme depuis Releases , en choisissant une version v3.7.0 ou ultérieure.
Décompressez le fichier archive. Cela crée un répertoire contenant les binaires.
Ajoutez les binaires exécutables à votre chemin d’accès. Par exemple, renommez et/ou déplacez les binaires vers un répertoire de votre chemin d’accès (comme /usr/local/bin), ou ajoutez le répertoire créé à l’étape précédente à votre chemin d’accès.

Portes fonctionnelles

Mon, 01 Jan 0001 00:00:00 +0000

Cette page présente un aperçu des diverses options de fonctionnalité qu’un administrateur peut spécifier sur etcd.

Voir étapes du fonctionnement pour une explication des étapes d’une fonctionnalité.

Aperçu

Les portes fonctionnelles sont un ensemble de paires clé=valeur qui décrivent les fonctionnalités d’etcd. Vous pouvez activer ou désactiver ces fonctionnalités à l’aide du drapeau de ligne de commande --feature-gates sur etcd.

FAQ

Mon, 01 Jan 0001 00:00:00 +0000

etcd, général

Qu’est-ce qu’etcd ?

etcd est un magasin clé-valeur distribué cohérent. Principalement utilisé comme service de coordination indépendant dans les systèmes distribués. Conçu pour stocker de petites quantités de données pouvant tenir entièrement en mémoire.

Comment prononce-t-on etcd ?

etcd se prononce /ˈɛtsiːdiː/ et signifie « répertoire etc distribué ».

Les clients doivent-ils envoyer des requêtes au leader etcd ?

Raft est basé sur un leader ; le leader gère toutes les requêtes clients nécessitant un consensus au sein du cluster. Toutefois, le client n’a pas besoin de savoir quel nœud est le leader. Toute requête nécessitant un consensus envoyée à un suiveur est automatiquement redirigée vers le leader. Les requêtes ne nécessitant pas de consensus (par exemple, les lectures sérialisées) peuvent être traitées par n’importe quel membre du cluster.

Bibliothèques et outils

Mon, 01 Jan 0001 00:00:00 +0000

Notez que les bibliothèques et outils tiers (non hébergés sur https://github.com/etcd-io ) mentionnés ci-dessous ne sont pas testés ni entretenus par l’équipe etcd. Avant de les utiliser, les utilisateurs sont invités à les lire et à les examiner.

Outils

etcdctl - Client en ligne de commande pour etcd
etcd-dump - Utilitaire en ligne de commande pour sauvegarder/restaurer etcd.
etcd-fs - Système de fichiers FUSE pour etcd
etcddir - Synchronisation en temps réel entre etcd et un répertoire local. Fonctionne sous Windows et Linux.
etcd-browser - Éditeur web de magasin clé-valeur pour etcd utilisant AngularJS
etcd-lock - Implémentation d’élection de maître et de verrouillage lecture/écriture distribué utilisant etcd - Prend en charge la version 2
etcd-console - Éditeur web de magasin clé-valeur pour etcd utilisant PHP
etcd-viewer - Éditeur/visualiseur de magasin clé-valeur etcd écrit en Java
etcdtool - Export/Import/Edit répertoire etcd en tant que JSON/YAML/TOML et validation du répertoire à l’aide d’un schéma JSON
etcdloadtest - Client de test de charge en ligne de commande pour etcd 3.0 et versions ultérieures
etcd-tui - Une interface utilisateur moderne en mode terminal (TUI) pour interagir avec votre base de données etcd. Parcourez les clés, affichez les valeurs, filtrez les données et gérez votre cluster etcd directement depuis votre terminal.
etcdfinder - Une interface web moderne et ultra-rapide pour etcd, avec recherche instantanée. Prend en charge à la fois etcd v2 et v3.
lucas - Un visualiseur de paires clé-valeur basé sur web pour les clusters etcd3.0+ de Kubernetes.
etcd-manager - Outil graphique et client moderne, efficace, multiplateforme et gratuit pour etcd 3.x. Disponible pour Windows, Linux et Mac.
etcd-backup-restore - Utilitaire permettant de sauvegarder et de restaurer de manière périodique et incrémentielle etcd.
etcd-druid - Opérateur Kubernetes permettant de déployer des clusters etcd et de gérer les opérations de gestion de jour 2.
etcdadm - Outil en ligne de commande pour gérer un cluster etcd.
etcd-defrag - Outil de défragmentation etcd plus facile à utiliser et plus intelligent.
etcdhelper - Plugin pour la plateforme IntelliJ pour etcd.

Bibliothèques

Les sections ci-dessous listent les bibliothèques clientes etcd par langage.

Comment ajouter et supprimer des membres

Mon, 01 Jan 0001 00:00:00 +0000

member pour ajouter, supprimer ou mettre à jour le membre :

# For each machine
TOKEN=my-etcd-token-1
CLUSTER_STATE=new
NAME_1=etcd-node-1
NAME_2=etcd-node-2
NAME_3=etcd-node-3
HOST_1=10.240.0.13
HOST_2=10.240.0.14
HOST_3=10.240.0.15
CLUSTER=${NAME_1}=http://${HOST_1}:2380,${NAME_2}=http://${HOST_2}:2380,${NAME_3}=http://${HOST_3}:2380

# For node 1
THIS_NAME=${NAME_1}
THIS_IP=${HOST_1}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 \
	--listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 \
	--listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} \
	--initial-cluster-token ${TOKEN}

# For node 2
THIS_NAME=${NAME_2}
THIS_IP=${HOST_2}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 \
	--listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 \
	--listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} \
	--initial-cluster-token ${TOKEN}

# For node 3
THIS_NAME=${NAME_3}
THIS_IP=${HOST_3}
etcd --data-dir=data.etcd --name ${THIS_NAME} \
	--initial-advertise-peer-urls http://${THIS_IP}:2380 \
	--listen-peer-urls http://${THIS_IP}:2380 \
	--advertise-client-urls http://${THIS_IP}:2379 \
	--listen-client-urls http://${THIS_IP}:2379 \
	--initial-cluster ${CLUSTER} \
	--initial-cluster-state ${CLUSTER_STATE} \
	--initial-cluster-token ${TOKEN}

Ensuite, remplacez un membre avec les commandes member remove et member add :

Signalement de bogues

Mon, 01 Jan 0001 00:00:00 +0000

Si une partie du projet etcd présente des bogues ou des erreurs de documentation, veuillez nous en informer en ouvrant une demande . Nous prenons très au sérieux les bogues et les erreurs, et considérons qu’aucun problème n’est trop petit. Avant de créer un rapport de bogue, veuillez vérifier qu’une demande signalant le même problème n’existe pas déjà.

Pour que le rapport de bogues soit précis et facile à comprendre, veuillez essayer de rédiger des rapports de bogues qui sont :

Optimisation

Mon, 01 Jan 0001 00:00:00 +0000

Les paramètres par défaut d’etcd devraient fonctionner correctement pour les installations sur un réseau local où la latence réseau moyenne est faible. Toutefois, lors de l’utilisation d’etcd sur plusieurs centres de données ou sur des réseaux à forte latence, il se peut que les paramètres d’intervalle de battement et de délai d’élection nécessitent une adaptation.

Le réseau n’est pas la seule source de latence. Chaque requête et réponse peut être affectée par des disques lents sur le leader et le suiveur. Chacun de ces délais d’attente représente le temps total écoulé entre la requête et la réponse réussie de l’autre machine.

Protocole du service de découverte

Mon, 01 Jan 0001 00:00:00 +0000

Le protocole de service de découverte aide un nouveau membre etcd à découvrir tous les autres membres du cluster pendant la phase d’initialisation, en utilisant une URL de découverte partagée.

Le protocole de service de découverte n’est utilisé que pendant la phase d’amorçage du cluster, et ne peut pas être utilisé pour la reconfiguration en temps réel ou la surveillance du cluster.

Le protocole utilise un nouveau jeton de découverte pour initialiser un unique cluster etcd. Souvenez-vous qu’un jeton de découverte ne peut représenter qu’un seul cluster etcd. Dès que le protocole de découverte associé à ce jeton est lancé, même s’il échoue en cours de route, il ne doit pas être utilisé pour initialiser un autre cluster etcd.

Protocole du service de découverte

Mon, 01 Jan 0001 00:00:00 +0000

Le protocole de service de découverte aide un nouveau membre etcd à découvrir tous les autres membres du cluster pendant la phase d’initialisation, en utilisant un jeton de découverte partagé et une liste d’extrémités.

Conventions de journalisation

Mon, 01 Jan 0001 00:00:00 +0000

etcd utilise la bibliothèque zap pour la journalisation de la sortie de l’application, catégorisée en niveaux. Le niveau d’un message de journalisation est déterminé selon les conventions suivantes :

Les journaux DebugLevel sont généralement volumineux et sont habituellement désactivés en production.
- Exemples :
  - Envoyer un message normal à un pair distant
  - Écrire une entrée de journal sur le disque
InfoLevel est la priorité de journalisation par défaut.
- Exemples :
  - Configuration au démarrage
  - Effectuer un instantané
  - Ajouter un nouveau nœud au cluster
  - Ajouter un nouvel utilisateur au sous-système d’authentification
Les journaux de niveau Warn sont plus importants que ceux de niveau Info, mais ne nécessitent pas de revue humaine individuelle.

Modules Go

Mon, 01 Jan 0001 00:00:00 +0000

Le projet etcd (à partir de la version 3.5) est organisé en plusieurs modules golang hébergés dans un référentiel unique .

Les modules suivants sont disponibles :

go.etcd.io/etcd/api/v3 - contient les définitions d’API (protos et bibliothèques générées à partir de protos) qui définissent le protocole de communication entre les clients et le serveur etcd.
go.etcd.io/etcd/pkg/v3 - ensemble de packages d’utilitaires utilisés par etcd sans être spécifiques à etcd lui-même. Un package doit être placé ici uniquement s’il pourrait éventuellement être déplacé vers son propre dépôt à l’avenir. Évitez d’ajouter ici du code qui a de nombreux dépendances, car celles-ci deviendraient automatiquement des dépendances de la bibliothèque cliente (que nous souhaitons garder légère).

Modèle de données

Mon, 01 Jan 0001 00:00:00 +0000

etcd est conçu pour stocker de manière fiable des données peu fréquemment mises à jour et fournir des requêtes de surveillance fiables. etcd expose les versions antérieures des paires clé-valeur afin de prendre en charge des instantanés à faible coût et les événements de historique de surveillance (« requêtes de voyage dans le temps »). Un modèle de données persistant, à plusieurs versions et contrôlant la concurrence s’adapte parfaitement à ces cas d’utilisation.

etcd conception client

Mon, 01 Jan 0001 00:00:00 +0000

Conception du client etcd

Gyuho Lee (github.com/gyuho, Amazon Web Services, Inc.), Joe Betz (github.com/jpbetz, Google Inc.)

Introduction

Le serveur etcd a démontré sa robustesse au fil de nombreuses années de tests d’injection d’erreurs. La logique d’application la plus complexe est déjà gérée par le serveur etcd et ses magasins de données (par exemple, la gestion de l’appartenance au cluster est transparente pour les clients, les propositions étant acheminées au leader au niveau du protocole Raft). Bien que les composants du serveur soient corrects, leur interaction avec les clients nécessite un ensemble différent de protocoles complexes afin de garantir leur correction et une haute disponibilité en cas de défaillance. Idéalement, le serveur etcd fournit une vue logique unique d’un cluster composé de plusieurs machines physiques, et le client implémente un basculement automatique entre les réplicas. Ce document décrit les choix architecturaux du client ainsi que leurs détails d’implémentation.

etcd design membre apprenant

Mon, 01 Jan 0001 00:00:00 +0000

etcd Membre apprenant

Gyuho Lee (github.com/gyuho, Amazon Web Services, Inc.), Joe Betz (github.com/jpbetz, Google Inc.)

Contexte

La reconfiguration du membership a été l’un des plus grands défis opérationnels. Examinons les défis courants.

1. Nouveau membre de cluster surcharge le leader

Un membre etcd nouvellement joint démarre sans données, ce qui entraîne un plus grand nombre de mises à jour provenant du leader jusqu’à ce qu’il rattrape la log du leader. Le réseau du leader est alors plus susceptible d’être surchargé, bloquant ou perdant les battements de cœur envoyés aux suiveurs. Dans ce cas, un suiveur peut atteindre son délai d’élection et déclencher une nouvelle élection de leader. Ainsi, un cluster comportant un nouveau membre est plus vulnérable à une élection de leader. À la fois l’élection de leader et la propagation ultérieure des mises à jour vers le nouveau membre sont sujettes à provoquer des périodes d’indisponibilité du cluster (voir Figure 1).

etcd conception de l'authentification v3

Mon, 01 Jan 0001 00:00:00 +0000

Pourquoi ne pas réutiliser le système d’authentification v2 ?

Le protocole v3 utilise gRPC comme transport, à la place d’une interface RESTful comme dans la v2. Ce nouveau protocole offre l’opportunité d’améliorer et d’évoluer la conception de la v2. Par exemple, l’authentification v3 repose sur une authentification basée sur la connexion, contrairement à l’authentification par requête plus lente de la v2. En outre, les sémantiques de l’authentification v2 s’avèrent souvent peu pratiques en pratique lorsqu’il s’agit d’assurer la cohérence, ce qui sera expliqué dans les sections suivantes. Pour la v3, une description et une implémentation clairement définies du mécanisme d’authentification corrigent les déficiences du système d’authentification v2.

etcd API

Mon, 01 Jan 0001 00:00:00 +0000

Ce document a pour objectif de présenter une vue d’ensemble des principes fondamentaux de l’API v3 d’etcd. Il ne doit pas être confondu avec l’API etcd v2, dépréciée à partir d’etcd v3.5. Il ne prétend pas être exhaustif, mais vise à se concentrer sur les idées de base nécessaires à la compréhension d’etcd, sans les distractions des appels d’API moins courants. Toutes les API etcd sont définies dans des services gRPC , qui catégorisent les appels de procédure distante (RPC) compris par le serveur etcd. Une liste complète de toutes les RPC etcd est documentée au format markdown dans le listing des API gRPC .

etcd fichiers de stockage persistant

Mon, 01 Jan 0001 00:00:00 +0000

Ce document explique le format de stockage persistant d’etcd : nomenclature, contenu et outils permettant aux développeurs d’en inspecter le contenu. À l’avenir, ce document devrait être mis à jour pour refléter les évolutions du modèle de stockage. Il s’adresse aux développeurs d’etcd afin de les aider dans leurs besoins de récupération de données.

Prérequis

Les articles suivants fournissent des informations de fond utiles pour ce document :

etcd Garanties de l'API

Mon, 01 Jan 0001 00:00:00 +0000

etcd est un magasin clé-valeur cohérent et durable. Le magasin clé-valeur est exposé via des [services gRPC]. etcd garantit les plus fortes garanties de cohérence et de durabilité pour un système distribué. Cette spécification énumère les garanties d’API offertes par etcd.

API à prendre en compte

APIs KV
- Range
- RangeStream
- Put
- Delete
- Transaction
APIs de surveillance
- Surveillance
APIs de bail
- Octroyer
- [Révoquer]
- Maintien de vie

L’API KV permet de lire et de manipuler directement le magasin de paires clé-valeur. L’API surveillance permet de s’abonner aux modifications apportées au magasin de paires clé-valeur. L’API bail permet d’attribuer une durée de vie à une clé.

etcd par rapport aux autres magasins clé-valeur

Mon, 01 Jan 0001 00:00:00 +0000

Le nom « etcd » provient de deux idées : le dossier unix « /etc » et les systèmes « d »istribués. Le dossier « /etc » est un emplacement destiné au stockage des données de configuration d’un système unique, tandis qu’etcd stocke les informations de configuration pour des systèmes distribués à grande échelle. Ainsi, un « d »istribué « /etc » devient « etcd ».

etcd est conçu comme une base commune pour les systèmes distribués à grande échelle. Il s’agit de systèmes qui ne tolèrent jamais une opération en split-brain et sont prêts à sacrifier la disponibilité pour atteindre cet objectif. etcd stocke les métadonnées de manière cohérente et résistante aux pannes. Un cluster etcd vise à offrir un stockage clé-valeur avec une stabilité, une fiabilité, une évolutivité et des performances de niveau supérieur.

Glossaire

Mon, 01 Jan 0001 00:00:00 +0000

Ce document définit les différents termes utilisés dans la documentation, la ligne de commande et le code source d’etcd.

Alarme

Le serveur etcd déclenche une alarme chaque fois que le cluster nécessite une intervention opérationnelle pour rester fiable.

Authentification

L’authentification gère les autorisations d’accès des utilisateurs aux ressources etcd.

Client

Un client se connecte au cluster etcd pour émettre des requêtes de service, telles que la récupération de paires clé-valeur, l’écriture de données ou la surveillance des mises à jour.

Mettre en place un cluster local

Mon, 01 Jan 0001 00:00:00 +0000

Pour les déploiements de test et de développement, la méthode la plus rapide et la plus simple consiste à configurer un cluster local. Pour un déploiement en production, reportez-vous à la section clustering .

Cluster autonome local

Démarrage d’un cluster

Exécutez la commande suivante pour déployer un cluster etcd en tant que cluster autonome :

$ ./etcd
...

Si le binaire etcd n’est pas présent dans le répertoire de travail courant, il se peut qu’il se trouve soit à $GOPATH/bin/etcd, soit à /usr/local/bin/etcd. Exécutez la commande en conséquence.

Interaction avec etcd

Mon, 01 Jan 0001 00:00:00 +0000

Les utilisateurs interagissent généralement avec etcd en définissant ou en récupérant la valeur d’une clé. Cette section décrit comment effectuer ces opérations à l’aide d’etcdctl, un outil en ligne de commande pour interagir avec le serveur etcd. Les concepts décrits ici s’appliquent également aux API gRPC ou aux API des bibliothèques clientes.

La version de l’API utilisée par etcdctl pour communiquer avec etcd peut être définie à 2 ou 3 via la variable d’environnement ETCDCTL_API. Par défaut, etcdctl sur la branche master (3.4) utilise l’API v3, tandis que les versions antérieures (3.3 et antérieures) utilisent par défaut l’API v2.

Pourquoi utiliser une passerelle gRPC

Mon, 01 Jan 0001 00:00:00 +0000

etcd v3 utilise gRPC comme protocole de messagerie. Le projet etcd inclut un client Go basé sur gRPC ainsi qu’une utilitaire en ligne de commande, etcdctl , pour communiquer avec un cluster etcd via gRPC. Pour les langages ne disposant pas de prise en charge gRPC, etcd fournit une passerelle gRPC en JSON. Cette passerelle fournit un proxy RESTful qui traduit les requêtes HTTP/JSON en messages gRPC.

Utilisation de la passerelle gRPC

La passerelle accepte une correspondance JSON pour les définitions de messages du protocole buffer de etcd . Notez que les champs key et value sont définis comme des tableaux d’octets et doivent donc être encodés en base64 dans le JSON. Les exemples suivants utilisent curl, mais tout client HTTP/JSON devrait fonctionner de la même manière.

Découverte et nommage gRPC

Mon, 01 Jan 0001 00:00:00 +0000

etcd fournit un résolveur gRPC afin de prendre en charge un système de noms alternatif qui récupère les points d’accès depuis etcd pour la découverte de services gRPC. Le mécanisme sous-jacent repose sur la surveillance des mises à jour des clés préfixées par le nom du service.

Notez que cette fonctionnalité est expérimentale car elle dépend du paquet google.golang.org/grpc/resolver , qui reste expérimental dans grpc-go.

Utilisation de la découverte etcd avec go-grpc

Le client etcd fournit un résolveur gRPC permettant de résoudre les points d’accès gRPC à l’aide d’un backend etcd. Le résolveur est initialisé avec un client etcd :

Intégration d'etcd dans une application Go

Mon, 01 Jan 0001 00:00:00 +0000

Le paquet go etcd embed fournit un moyen simple d’intégrer un serveur etcd directement dans votre application.

Pour plus de détails, consultez la documentation du paquet embed .

Limites système

Mon, 01 Jan 0001 00:00:00 +0000

Limite de taille de requête

etcd est conçu pour gérer des paires clé-valeur de petite taille, typiques des métadonnées. Les requêtes plus grandes fonctionnent, mais peuvent augmenter la latence des autres requêtes. Par défaut, la taille maximale de toute requête est de 1,5 MiB. Cette limite est configurable via le drapeau --max-request-bytes du serveur etcd.

Limite de taille du stockage

La limite par défaut de taille de stockage est de 2 GiB, configurable à l’aide du drapeau --quota-backend-bytes. Une taille maximale de 8 GiB est recommandée pour les environnements normaux, et etcd émet un avertissement au démarrage si la valeur configurée la dépasse.

etcd features

Mon, 01 Jan 0001 00:00:00 +0000

Ce document présente un aperçu des fonctionnalités d’etcd afin d’aider les utilisateurs à mieux comprendre ces fonctionnalités et le processus de mise hors service associé. Si vous souhaitez en savoir plus sur la manière dont les fonctionnalités sont développées dans etcd, veuillez consulter ces guides de développement .

Les fonctionnalités d’etcd sont classées en trois états : expérimentales, stables et non sécurisées. Vous pouvez obtenir la liste des fonctionnalités en exécutant etcd --help.

Référence de l'API

Mon, 01 Jan 0001 00:00:00 +0000

Cette référence d’API est générée automatiquement à partir des fichiers nommés .proto.

service `Auth` (api/etcdserverpb/rpc.proto)

Méthode	Type de requête	Type de réponse	Description
AuthEnable	AuthEnableRequest	AuthEnableResponse	AuthEnable active l’authentification.
AuthDisable	AuthDisableRequest	AuthDisableResponse	AuthDisable désactive l’authentification.
AuthStatus	AuthStatusRequest	AuthStatusResponse	AuthStatus affiche l’état de l’authentification.
Authenticate	AuthenticateRequest	AuthenticateResponse	Authenticate traite une requête d’authentification.
UserAdd	AuthUserAddRequest	AuthUserAddResponse	UserAdd ajoute un nouvel utilisateur. Le nom d’utilisateur ne peut pas être vide.
UserGet	AuthUserGetRequest	AuthUserGetResponse	UserGet obtient les informations détaillées d’un utilisateur.
UserList	AuthUserListRequest	AuthUserListResponse	UserList obtient la liste de tous les utilisateurs.
UserDelete	AuthUserDeleteRequest	AuthUserDeleteResponse	UserDelete supprime un utilisateur spécifié.
UserChangePassword	AuthUserChangePasswordRequest	AuthUserChangePasswordResponse	UserChangePassword modifie le mot de passe d’un utilisateur spécifié.
UserGrantRole	AuthUserGrantRoleRequest	AuthUserGrantRoleResponse	UserGrant accorde un rôle à un utilisateur spécifié.
UserRevokeRole	AuthUserRevokeRoleRequest	AuthUserRevokeRoleResponse	UserRevokeRole retire un rôle à un utilisateur spécifié.
RoleAdd	AuthRoleAddRequest	AuthRoleAddResponse	RoleAdd ajoute un nouveau rôle. Le nom de rôle ne peut pas être vide.
RoleGet	AuthRoleGetRequest	AuthRoleGetResponse	RoleGet obtient les informations détaillées sur un rôle.
RoleList	AuthRoleListRequest	AuthRoleListResponse	RoleList obtient la liste de tous les rôles.
RoleDelete	AuthRoleDeleteRequest	AuthRoleDeleteResponse	RoleDelete supprime un rôle spécifié.
RoleGrantPermission	AuthRoleGrantPermissionRequest	AuthRoleGrantPermissionResponse	RoleGrantPermission accorde une permission sur une clé ou une plage spécifique à un rôle spécifié.
RoleRevokePermission	AuthRoleRevokePermissionRequest	AuthRoleRevokePermissionResponse	RoleRevokePermission retire une permission sur une clé ou une plage spécifique à un rôle spécifié.

service `Cluster` (api/etcdserverpb/rpc.proto)

Méthode	Type de requête	Type de réponse	Description
MemberAdd	MemberAddRequest	MemberAddResponse	MemberAdd ajoute un membre au cluster.
MemberRemove	MemberRemoveRequest	MemberRemoveResponse	MemberRemove supprime un membre existant du cluster.
MemberUpdate	MemberUpdateRequest	MemberUpdateResponse	MemberUpdate met à jour la configuration du membre.
MemberList	MemberListRequest	MemberListResponse	MemberList liste tous les membres du cluster.
MemberPromote	MemberPromoteRequest	MemberPromoteResponse	MemberPromote promeut un membre de type apprenant Raft (non votant) en membre votant Raft.

service `KV` (api/etcdserverpb/rpc.proto)

Méthode	Type de requête	Type de réponse	Description
Range	RangeRequest	RangeResponse	Range récupère les clés dans la plage depuis le magasin clé-valeur.
Put	PutRequest	PutResponse	Put insère la clé donnée dans le magasin clé-valeur. Une requête Put incrémente la révision du magasin clé-valeur et génère un événement dans l’historique des événements.
DeleteRange	DeleteRangeRequest	DeleteRangeResponse	DeleteRange supprime la plage donnée depuis le magasin clé-valeur. Une requête de suppression incrémente la révision du magasin clé-valeur et génère un événement de suppression dans l’historique des événements pour chaque clé supprimée.
Txn	TxnRequest	TxnResponse	Txn traite plusieurs requêtes dans une seule transaction. Une requête Txn incrémente la révision du magasin clé-valeur et génère des événements avec la même révision pour chaque requête terminée. Il est interdit de modifier la même clé plusieurs fois au sein d’une même transaction.
Compact	CompactionRequest	CompactionResponse	Compact compresse l’historique des événements dans le magasin clé-valeur etcd. Le magasin clé-valeur doit être régulièrement compacté, sinon l’historique des événements continuera de croître indéfiniment.

service `Lease` (api/etcdserverpb/rpc.proto)

Méthode	Type de requête	Type de réponse	Description
LeaseGrant	LeaseGrantRequest	LeaseGrantResponse	LeaseGrant crée un bail qui expire si le serveur ne reçoit pas de demande de maintien de vie dans un délai défini. Toutes les clés associées au bail expireront et seront supprimées si le bail expire. Chaque clé expirée génère un événement de suppression dans l’historique des événements.
LeaseRevoke	LeaseRevokeRequest	LeaseRevokeResponse	LeaseRevoke révoque un bail. Toutes les clés associées au bail expireront et seront supprimées.
LeaseKeepAlive	LeaseKeepAliveRequest	LeaseKeepAliveResponse	LeaseKeepAlive maintient le bail actif en transmettant en continu des demandes de maintien de vie du client vers le serveur et des réponses de maintien de vie du serveur vers le client.
LeaseTimeToLive	LeaseTimeToLiveRequest	LeaseTimeToLiveResponse	LeaseTimeToLive récupère les informations relatives au bail.
LeaseLeases	LeaseLeasesRequest	LeaseLeasesResponse	LeaseLeases liste tous les bails existants.

service `Maintenance` (api/etcdserverpb/rpc.proto)

Méthode	Type de requête	Type de réponse	Description
Alarme	AlarmRequest	AlarmResponse	Alarme active, désactive et interroge les alarmes relatives à l’intégrité du cluster.
Statut	StatusRequest	StatusResponse	Statut obtient l’état du membre.
Défragmentation	DefragmentRequest	DefragmentResponse	Défragmentation défragmente la base de données du membre backend afin de récupérer de l’espace de stockage.
Hachage	HashRequest	HashResponse	Hachage calcule le hachage de l’espace de clés backend entier, y compris les clés, les bails et les autres compartiments dans le stockage. Conçu uniquement à des fins de test ! Ne pas compter sur cette fonctionnalité en production avec des transactions en cours, car l’opération Hachage ne détient pas de verrous MVCC. Utilisez plutôt l’API “HashKV” pour vérifier la cohérence du compartiment “key”.
HachageKV	HashKVRequest	HashKVResponse	HachageKV calcule le hachage de toutes les clés MVCC jusqu’à une révision donnée. Il ne parcourt que le compartiment “key” dans le stockage backend.
Instantané	SnapshotRequest	SnapshotResponse	Instantané envoie un instantané de l’ensemble du backend depuis un membre vers un client via un flux.
Transfert du leader	MoveLeaderRequest	MoveLeaderResponse	Transfert du leader demande au nœud leader actuel de transférer son leadership au destinataire.
Mise à jour vers une version inférieure	DowngradeRequest	DowngradeResponse	Mise à jour vers une version inférieure demande une mise à jour vers une version inférieure, vérifie la faisabilité ou annule la mise à jour vers une version inférieure sur la version du cluster. Prise en charge depuis etcd 3.5.

service `Watch` (api/etcdserverpb/rpc.proto)

Méthode	Type de requête	Type de réponse	Description
Surveillance	WatchRequest	WatchResponse	La surveillance observe les événements survenus ou survenant. Les entrées et sorties sont des flux ; le flux d’entrée sert à créer et annuler des observateurs, tandis que le flux de sortie envoie les événements. Une seule requête RPC de surveillance peut surveiller plusieurs plages de clés, en diffusant les événements de plusieurs surveillance simultanément. L’historique complet des événements peut être surveillé à partir de la dernière révision de compactage.

message `AlarmMember` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
memberID	memberID est l’identifiant du membre associé à l’alarme déclenchée.	uint64
alarm	alarm est le type d’alarme qui a été déclenchée.	AlarmType

message `AlarmRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
action	action est le type de requête d’alarme à émettre. L’action peut être GET pour obtenir les états d’alarme, ACTIVATE pour activer une alarme, ou DEACTIVATE pour désactiver une alarme activée.	AlarmAction
memberID	memberID est l’identifiant du membre associé à l’alarme. Si memberID est 0, la requête d’alarme concerne tous les membres.	uint64
alarm	alarm est le type d’alarme à prendre en compte pour cette requête.	AlarmType

message `AlarmResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader
alarms	alarms est une liste d’alertes associées à la requête d’alerte.	(slice de) AlarmMember

message `AuthDisableRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option

message `AuthDisableResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader

message `AuthEnableRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option

message `AuthEnableResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader

message `AuthRoleAddRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
name	name est le nom du rôle à ajouter au système d’authentification.	string

message `AuthRoleAddResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader

message `AuthRoleDeleteRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
role		chaîne de caractères

message `AuthRoleDeleteResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader

message `AuthRoleGetRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
role		chaîne de caractères

message `AuthRoleGetResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
header		ResponseHeader
perm		(tranche de) authpb.Permission

message `AuthRoleGrantPermissionRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
name	name est le nom du rôle auquel la permission sera accordée.	string
perm	perm est la permission à accorder au rôle.	authpb.Permission

message `AuthRoleGrantPermissionResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader

message `AuthRoleListRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option

message `AuthRoleListResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader
roles		(tranche de) string

message `AuthRoleRevokePermissionRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
role		string
key		bytes
range_end		bytes

message `AuthRoleRevokePermissionResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader

message `AuthStatusRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option

message `AuthStatusResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader
enabled		bool
authRevision	authRevision est la révision actuelle du magasin d’authentification	uint64

message `AuthUserAddRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
name		string
password		string
options		authpb.UserAddOptions
hashedPassword		string

message `AuthUserAddResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader

message `AuthUserChangePasswordRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
name	name est le nom de l’utilisateur dont le mot de passe est modifié.	string
password	password est le nouveau mot de passe de l’utilisateur. Notez que ce champ sera supprimé au niveau de l’API.	string
hashedPassword	hashedPassword est le nouveau mot de passe de l’utilisateur. Notez que ce champ sera initialisé au niveau de l’API.	string

message `AuthUserChangePasswordResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader

message `AuthUserDeleteRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
name	name est le nom de l’utilisateur à supprimer.	string

message `AuthUserDeleteResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader

message `AuthUserGetRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
name		string

message `AuthUserGetResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader
roles		(tranche de) string

message `AuthUserGrantRoleRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
user	user est le nom de l’utilisateur auquel il faut attribuer un rôle donné.	string
role	role est le nom du rôle à attribuer à l’utilisateur.	string

message `AuthUserGrantRoleResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader

message `AuthUserListRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option

message `AuthUserListResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader
users		(tranche de) string

message `AuthUserRevokeRoleRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
name		string
role		string

message `AuthUserRevokeRoleResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader

message `AuthenticateRequest` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
name		string
password		string

message `AuthenticateResponse` (api/etcdserverpb/rpc.proto)

Champ	Description	Type
(versionpb.etcd_version_msg)		option
header		ResponseHeader
token	le jeton est un jeton autorisé pouvant être utilisé dans les RPC suivants	string

message `CompactionRequest` (api/etcdserverpb/rpc.proto)

CompactionRequest compacte le magasin clé-valeur jusqu’à une révision donnée. Toutes les clés obsolètes dont la révision est inférieure à la révision de compactage seront supprimées.

Référence API : concurrence

Mon, 01 Jan 0001 00:00:00 +0000

Cette référence d’API est générée automatiquement à partir des fichiers nommés .proto.

service `Lock` (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Le service de verrouillage expose des fonctionnalités de verrouillage côté client sous forme d’une interface gRPC.

Méthode	Type de requête	Type de réponse	Description
Lock	LockRequest	LockResponse	Lock acquiert un verrou partagé distribué sur un verrou nommé donné. En cas de succès, elle retourne une clé unique qui reste existante tant que le verrou est détenu par l’appelant. Cette clé peut être utilisée conjointement avec des transactions afin de garantir en toute sécurité que les mises à jour sur etcd ne s’effectuent qu’en tenant le verrou. Le verrou est détenu jusqu’à ce que Unlock soit appelé sur la clé ou que le bail associé au propriétaire expire.
Unlock	UnlockRequest	UnlockResponse	Unlock prend une clé retournée par Lock et libère la possession du verrou. Le prochain appelant de Lock en attente du verrou est alors réveillé et obtient la possession du verrou.

message `LockRequest` (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Champ	Description	Type
name	name est l’identifiant de la verrouille partagée distribuée à acquérir.	bytes
lease	lease est l’ID du bail qui sera attaché à la possession du verrou. Si le bail expire ou est révoqué et qu’il détient actuellement le verrou, celui-ci est automatiquement libéré. Les appels à Lock avec le même bail seront traités comme une seule acquisition ; verrouiller deux fois avec le même bail est sans effet.	int64

message `LockResponse` (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Champ	Description	Type
header		etcdserverpb.ResponseHeader
key	key est une clé qui existera dans etcd pendant toute la durée où l’appelant du verrou détient le verrou. Les utilisateurs ne doivent pas modifier cette clé, sinon le verrou peut présenter un comportement indéfini.	bytes

message `UnlockRequest` (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Champ	Description	Type
key	key est la clé d’acquisition du verrou octroyée par Lock.	bytes

message `UnlockResponse` (server/etcdserver/api/v3lock/v3lockpb/v3lock.proto)

Champ	Description	Type
header		etcdserverpb.ResponseHeader

service `Election` (server/etcdserver/api/v3election/v3electionpb/v3election.proto)

Le service d’élection expose des fonctionnalités d’élection côté client sous forme d’une interface gRPC.

Authentification

Mon, 01 Jan 0001 00:00:00 +0000

auth,user,role pour l’authentification :

export ETCDCTL_API=3
ENDPOINTS=localhost:2379

etcdctl --endpoints=${ENDPOINTS} role add root
etcdctl --endpoints=${ENDPOINTS} role get root

etcdctl --endpoints=${ENDPOINTS} user add root
etcdctl --endpoints=${ENDPOINTS} user grant-role root root
etcdctl --endpoints=${ENDPOINTS} user get root

etcdctl --endpoints=${ENDPOINTS} role add role0
etcdctl --endpoints=${ENDPOINTS} role grant-permission role0 readwrite foo
etcdctl --endpoints=${ENDPOINTS} user add user0
etcdctl --endpoints=${ENDPOINTS} user grant-role user0 role0

etcdctl --endpoints=${ENDPOINTS} auth enable
# now all client requests go through auth

etcdctl --endpoints=${ENDPOINTS} --user=user0:123 put foo bar
etcdctl --endpoints=${ENDPOINTS} get foo
# permission denied, user name is empty because the request does not issue an authentication request
etcdctl --endpoints=${ENDPOINTS} --user=user0:123 get foo
# user0 can read the key foo
etcdctl --endpoints=${ENDPOINTS} --user=user0:123 get foo1

Note :

Il s’agit simplement d’un squelette qui doit être complété et mis à jour avec des informations supplémentaires sur l’authentification. Le texte ci-dessus n’est qu’un exemple de code.

Options de configuration

Mon, 01 Jan 0001 00:00:00 +0000

Vous pouvez configurer etcd à l’aide des éléments suivants :

Options en ligne de commande
Variables d’environnement : chaque option a une variable d’environnement correspondante dont le nom est identique, mais préfixé par ETCD_ et écrit en majuscules et [en notation snake case][]. Par exemple, --some-flag sera ETCD_SOME_FLAG.
Fichier de configuration

Avertissement

Avertissement : Si vous mélangez des options de configuration, les règles suivantes s’appliquent.

Les indicateurs en ligne de commande ont la priorité sur les variables d’environnement.
Si vous fournissez un fichier de configuration, tous les indicateurs en ligne de commande et les variables d’environnement sont ignorés.

Drapeaux de ligne de commande

Les indicateurs sont présentés ci-dessous selon le format --flag-name DEFAULT_VALUE.

Contrôle d'accès basé sur les rôles

Mon, 01 Jan 0001 00:00:00 +0000

Aperçu

L’authentification a été ajoutée à etcd 2.1. L’API v3 d’etcd a légèrement modifié l’API et l’interface utilisateur de la fonctionnalité d’authentification afin de mieux s’adapter au nouveau modèle de données. Ce guide vise à aider les utilisateurs à configurer une authentification basique et un contrôle d’accès basé sur les rôles dans etcd v3.

Utilisateurs et rôles spéciaux

Il existe un utilisateur spécial, root, et un rôle spécial, root.

Modèle de sécurité du transport

Mon, 01 Jan 0001 00:00:00 +0000

etcd prend en charge le chiffrement TLS automatique ainsi que l’authentification par certificats clients pour les communications clients vers serveur, ainsi que pour les communications entre pairs (serveur vers serveur / cluster). Notez qu’etcd n’active pas par défaut l’authentification basée sur RBAC ni la fonctionnalité d’authentification au niveau du transport afin de réduire les obstacles pour les utilisateurs débutants avec la base de données. En outre, modifier cette valeur par défaut constituerait une modification incompatible pour le projet, établie depuis 2013. Un cluster etcd qui n’active pas les fonctionnalités de sécurité peut exposer ses données à tout client.

Guide de clustering

Mon, 01 Jan 0001 00:00:00 +0000

Aperçu

Lancer un cluster etcd de manière statique exige que chaque membre connaisse un autre membre du cluster. Dans certains cas, les adresses IP des membres du cluster peuvent être inconnues à l’avance. Dans ces situations, le cluster etcd peut être initialisé à l’aide d’un service de découverte.

Une fois qu’un cluster etcd est en cours d’exécution, l’ajout ou la suppression de membres s’effectue via la reconfiguration en temps réel runtime reconfiguration . Pour mieux comprendre la conception sous-jacente à la reconfiguration en temps réel, nous recommandons de lire le document de conception de la configuration en temps réel .

Exécuter des clusters etcd dans des conteneurs

Mon, 01 Jan 0001 00:00:00 +0000

Le guide suivant explique comment exécuter etcd avec Docker en utilisant le processus de bootstrap statique static bootstrap process .

Docker

Afin d’exposer l’API etcd aux clients situés en dehors de l’hôte Docker, utilisez l’adresse IP hôte du conteneur. Voir docker inspect pour plus de détails sur la manière d’obtenir l’adresse IP. En alternative, spécifiez le drapeau --net=host à la commande docker run afin de passer outre la mise du conteneur dans une pile réseau séparée.

Exécuter des clusters etcd en tant que StatefulSet Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Ci-dessous montre comment effectuer le processus de bootstrap statique comme un StatefulSet Kubernetes .

Exemple de manifeste

Ce manifeste contient un service et un statefulset pour déployer un cluster etcd statique dans Kubernetes.

Si vous copiez le contenu du manifeste dans un fichier nommé etcd.yaml, vous pouvez l’appliquer à un cluster à l’aide de cette commande.

$ kubectl apply --filename etcd.yaml

Une fois appliqué, attendez que les pods soient prêts.

Modes de défaillance

Mon, 01 Jan 0001 00:00:00 +0000

Les défaillances sont fréquentes dans un déploiement à grande échelle de machines. Une machine défaillante est une machine dont le matériel ou le logiciel présente une anomalie. Plusieurs machines peuvent défaillir simultanément en cas de panne de courant ou de problèmes réseau. Plusieurs types de défaillances peuvent également survenir en même temps ; il est presque impossible d’énumérer toutes les situations de défaillance possibles.

Dans cette section, nous recensons les types d’pannes et discutons de la manière dont etcd est conçu pour y résister. La plupart des utilisateurs, sinon tous, peuvent associer une panne particulière à un type de panne spécifique. Pour se préparer aux rares pannes irréversibles , il est toujours recommandé de sauvegarder le cluster etcd.

Récupération après sinistre

Mon, 01 Jan 0001 00:00:00 +0000

etcd est conçu pour résister aux pannes de machines. Un cluster etcd se rétablit automatiquement après des pannes temporaires (par exemple, redémarrages de machine) et tolère jusqu’à (N-1)/2 pannes permanentes pour un cluster composé de N membres. Lorsqu’un membre subit une panne permanente, qu’elle soit due à une défaillance matérielle ou à une corruption du disque, il perd accès au cluster. Si le cluster perd définitivement plus de (N-1)/2 membres, il subit une panne catastrophique, perdant irrévocablement son quorum. Une fois le quorum perdu, le cluster ne peut plus atteindre de consensus et ne peut donc plus accepter de mises à jour.

etcd gateway

Mon, 01 Jan 0001 00:00:00 +0000

Qu’est-ce que la passerelle etcd

Le passerelle etcd est un proxy TCP simple qui achemine les données réseau vers le cluster etcd. La passerelle est sans état et transparente ; elle n’inspecte ni les requêtes clients ni les réponses du cluster. Elle ne termine pas les connexions TLS, ne réalise pas d’échanges TLS à la place de ses clients, ni ne vérifie si la connexion est sécurisée.

Proxie gRPC

Mon, 01 Jan 0001 00:00:00 +0000

Le proxy gRPC est un proxy inverse etcd sans état fonctionnant au niveau du protocole gRPC (L7). Le proxy est conçu pour réduire la charge de traitement totale imposée au cluster etcd principal. Pour assurer une évolutivité horizontale, il regroupe les requêtes d’API de surveillance et de bail. Pour protéger le cluster contre les clients abusifs, il met en mémoire tampon les requêtes portant sur des plages de clés.

Le proxy gRPC prend en charge plusieurs points d’entrée de serveur etcd. Au démarrage du proxy, il choisit aléatoirement un point d’entrée de serveur etcd à utiliser. Ce point d’entrée traite toutes les requêtes jusqu’à ce que le proxy détecte une défaillance. Si le proxy gRPC détecte une défaillance d’un point d’entrée, il bascule vers un autre point d’entrée, si disponible, afin de masquer les défaillances à ses clients. D’autres politiques de réessai, telles que le round-robin pondéré, pourraient être prises en charge à l’avenir.

Recommandations matérielles

Mon, 01 Jan 0001 00:00:00 +0000

etcd fonctionne généralement correctement avec des ressources limitées à des fins de développement ou de test ; il est courant de développer avec etcd sur un ordinateur portable ou une machine cloud peu coûteuse. Toutefois, lors de l’exécution de clusters etcd en production, certaines recommandations matérielles sont utiles pour une administration appropriée. Ces suggestions ne sont pas des règles strictes ; elles constituent un bon point de départ pour un déploiement productif robuste. Comme toujours, les déploiements doivent être testés avec des charges simulées avant d’être mis en production.

Maintenance

Mon, 01 Jan 0001 00:00:00 +0000

Aperçu

Un cluster etcd nécessite une maintenance périodique pour rester fiable. Selon les besoins d’une application etcd, cette maintenance peut généralement être automatisée et effectuée sans interruption de service ni dégradation significative des performances.

Toute maintenance etcd gère les ressources de stockage consommées par l’espace de clés etcd. Une gestion insuffisante de la taille de l’espace de clés est protégée par des quotas d’espace de stockage ; si un membre etcd manque d’espace, un quota déclenchera des alarmes à l’échelle du cluster, mettant le système en mode maintenance à opérations limitées. Pour éviter de manquer d’espace pour les écritures dans l’espace de clés, l’historique de l’espace de clés etcd doit être compacté. L’espace de stockage lui-même peut être récupéré en défragmentant les membres etcd. Enfin, des sauvegardes périodiques d’instantanés de l’état des membres etcd permettent de récupérer toute perte logique de données ou corruption involontaire causée par une erreur opérationnelle.

Surveillance d’etcd

Mon, 01 Jan 0001 00:00:00 +0000

Chaque serveur etcd fournit des informations de surveillance locales sur son port client via des points de terminaison HTTP. Les données de surveillance sont utiles à la fois pour le contrôle de santé du système et le débogage du cluster.

Point d’entrée de débogage

Si --log-level=debug est défini, le serveur etcd exporte des informations de débogage sur son port client sous le chemin /debug. Prenez garde à la définition de --log-level=debug, car cela entraînera une dégradation des performances et une journalisation verbose.

Performances

Mon, 01 Jan 0001 00:00:00 +0000

Comprendre les performances

etcd offre des performances stables et élevées de manière soutenue. Deux facteurs définissent les performances : la latence et le débit. La latence correspond au temps nécessaire pour accomplir une opération. Le débit correspond au nombre total d’opérations effectuées durant une période donnée. En général, la latence moyenne augmente lorsque le débit global augmente, lorsque etcd accepte des requêtes clientes concurrentes. Dans des environnements cloud courants, comme une instance standard n-4 sur Google Compute Engine (GCE) ou un type de machine équivalent sur AWS, un cluster etcd composé de trois membres exécute une requête en moins d’une milliseconde en charge légère, et peut traiter plus de 30 000 requêtes par seconde en charge lourde.

Conception de la reconfiguration à l'exécution

Mon, 01 Jan 0001 00:00:00 +0000

La reconfiguration à l’exécution est l’une des fonctionnalités les plus complexes et sujettes aux erreurs dans un système distribué, en particulier dans un système fondé sur le consensus comme etcd.

Lisez la suite pour en savoir plus sur la conception des commandes de reconfiguration en cours d’exécution d’etcd et sur la manière dont nous avons résolu ces problèmes.

Les modifications de configuration en deux phases maintiennent le cluster en sécurité

Dans etcd, toute reconfiguration en cours d’exécution doit suivre deux phases pour des raisons de sécurité. Par exemple, pour ajouter un membre, il faut d’abord informer le cluster de la nouvelle configuration, puis démarrer le nouveau membre.

Reconfiguration en cours d'exécution

Mon, 01 Jan 0001 00:00:00 +0000

etcd dispose d’un support pour la reconfiguration incrémentielle en temps d’exécution, ce qui permet aux utilisateurs de mettre à jour la composition du cluster en cours d’exécution.

Les requêtes de reconfiguration ne peuvent être traitées que lorsque la majorité des membres du cluster sont fonctionnels. Il est fortement recommandé de toujours disposer d’un cluster de taille supérieure à deux en production. Il est dangereux de supprimer un membre d’un cluster à deux membres. La majorité d’un cluster à deux membres est également de deux. En cas d’échec pendant le processus de suppression, le cluster pourrait ne pas être en mesure de progresser et nécessiterait un redémarrage suite à une défaillance de la majorité .

Plateformes prises en charge

Mon, 01 Jan 0001 00:00:00 +0000

Support tiers

etcd s’exécute sur différentes plates-formes, mais les garanties qu’il fournit dépendent du niveau de prise en charge de la plate-forme :

Niveau 1 : entièrement pris en charge par les mainteneurs [etcd][] ; etcd est garanti pour passer tous les tests, y compris les tests fonctionnels et de robustesse.
Niveau 2 : etcd est garanti pour passer les tests d’intégration et les tests bout en bout, mais pas nécessairement les tests fonctionnels ou de robustesse.
Niveau 3 : etcd est garanti pour être compilé, peut être légèrement testé (ou non), et doit donc être considéré comme instable.

Prise en charge actuelle

Le tableau suivant répertorie les plateformes actuellement prises en charge ainsi que leur niveau de prise en charge correspondant pour etcd :

Gestion des versions

Mon, 01 Jan 0001 00:00:00 +0000

Ce document décrit les versions prises en charge par le projet etcd.

Versioning des services et versions prises en charge

Les versions d’etcd sont exprimées sous la forme x.y.z, où x représente la version majeure, y la version mineure et z la version de correctif, conformément à la terminologie Semantic Versioning . Les nouvelles versions mineures peuvent ajouter des fonctionnalités supplémentaires à l’API.

Le projet etcd maintient des branches de version pour la version actuelle et les versions précédentes. Par exemple, lorsque v3.5 est la version actuelle, v3.4 est prise en charge. Lorsque v3.6 est publiée, v3.4 n’est plus pris en charge.

Corruption des données

Mon, 01 Jan 0001 00:00:00 +0000

etcd dispose d’une détection automatique des corruption de données intégrée afin d’éviter que l’état du membre ne diverge.

Activation détection corruption données

Détection de corruption de données possible à l’aide de :

Vérification initiale, activée avec le drapeau --experimental-initial-corrupt-check.
Vérification périodique de :
- Hachage de la révision compactée, activée avec le drapeau --experimental-compact-hash-check-enabled.
- Hachage de la dernière révision, activée avec le drapeau --experimental-corrupt-check-time.

La vérification initiale sera exécutée lors du démarrage du membre etcd. Le membre comparera son état persistant avec celui des autres membres et quittera l’exécution s’il détecte une incohérence.

Benchmark de l'utilisation de la mémoire de stockage

Mon, 01 Jan 0001 00:00:00 +0000

Deux composants du stockage etcd consomment de la mémoire physique. Le processus etcd alloue un index en mémoire afin d’accélérer la recherche des clés. La mémoire tampon de pages, gérée par le système d’exploitation, stocke les données récemment accessibles sur disque pour une réutilisation rapide.

L’index en mémoire stocke toutes les clés dans une structure de données arbre B , accompagnées de pointeurs vers les données sur disque (les valeurs). Chaque clé dans l’arbre B peut contenir plusieurs pointeurs, chacun faisant référence à une version différente de sa valeur. La consommation mémoire théorique de l’index en mémoire peut donc être approximée par la formule :

Benchmark de l'utilisation mémoire de la surveillance

Mon, 01 Jan 0001 00:00:00 +0000

Note

Les fonctionnalités de surveillance sont en développement actif, et leur utilisation mémoire peut évoluer au cours de ce développement. Nous ne prévoyons pas d’augmentation significative au-delà des valeurs indiquées ci-dessous.

Un objectif principal d’etcd est de prendre en charge un très grand nombre d’observateurs effectuant une surveillance massivement étendue. etcd vise à supporter O(10k) clients, O(100K) flux de surveillance (O(10) flux par client) et O(10M) surveillance totale (O(100) surveillance par flux). La mémoire consommée par chaque surveillance individuelle représente la plus grande partie de l’utilisation globale d’etcd, et constitue donc le point focal des optimisations actuelles et futures.

Benchmarking d'etcd v3

Mon, 01 Jan 0001 00:00:00 +0000

Machines physiques

Type de machine GCE n1-highcpu-2

1 disque SSD local dédiqué monté sous /var/lib/etcd
1 disque lent dédié pour le système d’exploitation
1,8 Go de mémoire
2 processeurs
version etcd 2.2.0

etcd cluster

1 membre etcd en mode démonstration v3

Test

Utilisez l’outil de benchmark etcd v3 .

Performances

lecture d’une seule clé

taille de la clé en octets	nombre de clients	QPS de lecture	latence au 90e percentile (ms)
256	1	2716	0,4
256	64	16623	6,1
256	256	16622	21,7

Les performances sont presque identiques à celles obtenues avec un gestionnaire de serveur vide.

Benchmarking etcd v2.2.0-rc-memory

Mon, 01 Jan 0001 00:00:00 +0000

Machine physique

Type de machine GCE n1-standard-2

1 disque SSD local dédié monté sous /var/lib/etcd
1 disque lent dédié pour le système d’exploitation
7,5 Go de mémoire
2 processeurs

etcd

etcd Version: 2.2.0-rc.0+git
Git SHA: 103cb5c
Go Version: go1.5
Go OS/Arch: linux/amd64

Test

Démarrez un cluster etcd composé de 3 membres, chacun utilisant 2 cœurs.

Benchmarking etcd v2.2.0-rc

Mon, 01 Jan 0001 00:00:00 +0000

Machine physique

Type de machine GCE n1-highcpu-2

1 disque SSD local dédié monté sous /var/lib/etcd
1 disque lent dédié pour le système d’exploitation
1,8 Go de mémoire
2 processeurs

etcd cluster

3 membres etcd 2.2.0-rc, chacun exécuté sur une seule machine.

Versions détaillées :

etcd Version: 2.2.0-alpha.1+git
Git SHA: 59a5a7e
Go Version: go1.4.2
Go OS/Arch: linux/amd64

En outre, nous utilisons 3 membres etcd 2.1.0 en phase alpha pour constituer le cluster et obtenir des performances de base. La tête du commit d’etcd est située à c7146bd5 , identique à celle utilisée dans benchmark etcd 2.1 .

Benchmarking d'etcd v2.2.0

Mon, 01 Jan 0001 00:00:00 +0000

Machines physiques

Type de machine GCE n1-highcpu-2

1 disque SSD local dédié monté en répertoire de données etcd
1 disque lent dédié pour le système d’exploitation
1,8 Go de mémoire
2 processeurs

etcd cluster

3 membres etcd 2.2.0, chacun exécuté sur une machine unique.

Versions détaillées :

etcd Version: 2.2.0
Git SHA: e4561dd
Go Version: go1.5
Go OS/Arch: linux/amd64

Test

Initialisez une autre machine, en dehors du cluster etcd, puis exécutez l’outil de benchmark HTTP hey avec un correctif de réutilisation de connexion pour envoyer des requêtes à chaque membre du cluster etcd. Consultez les instructions de benchmark pour obtenir le correctif et les étapes permettant de reproduire nos procédures.

Test de performance d'etcd v2.1.0

Mon, 01 Jan 0001 00:00:00 +0000

Machines physiques

Type de machine GCE n1-highcpu-2

1 disque SSD local dédié monté sous /var/lib/etcd
1 disque lent dédié pour le système d’exploitation
1,8 Go de mémoire
2 processeurs
version etcd 2.1.0 alpha

etcd cluster

3 membres etcd, chacun exécuté sur une machine unique

Test

Initialisez une autre machine et utilisez l’outil de benchmark HTTP hey pour envoyer des requêtes à chaque membre etcd. Consultez le guide de manipulation du benchmark pour des instructions détaillées.

Mise à jour des clusters etcd et des applications

Mon, 01 Jan 0001 00:00:00 +0000

Cette section contient les documents spécifiques à la mise à jour des clusters etcd et des applications.

Politique de mise à jour

Avant la mise à jour, notez qu’etcd ne prend en charge que les deux cas de mise à jour suivants :

Mise à jour correctif : Mise à jour entre des versions correctives du même numéro de version mineure (par exemple, 3.7.0 → 3.7.1).
Mise à jour mineure : Mise à jour d’une version mineure à la fois (par exemple, 3.6 → 3.7). Les mises à jour qui sautent une version mineure ne sont pas prises en charge et risquent de échouer. Mettez à jour vers la dernière version correctif avant de passer à la version mineure suivante.

Mise à jour d’un cluster etcd v3.x

Mise à niveau depuis etcd v2.3

Mettre à jour un cluster v2.3 vers la v3.0

Réduction de version des clusters etcd et des applications

Mon, 01 Jan 0001 00:00:00 +0000

Cette section contient les documents spécifiques à la rétrogradation des clusters etcd et des applications.

Réduction de la version d’un cluster etcd v3.x

Mettre à jour etcd de la version v3.5 à la version v3.6

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau de etcd v3.5 vers v3.6 peut être une mise à niveau progressive sans interruption de service :

un à un, arrêtez les processus etcd v3.5 et remplacez-les par des processus etcd v3.6
après avoir lancé tous les processus v3.6, les nouvelles fonctionnalités de la version v3.6 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Rétrogradation d'etcd de la version v3.7 à la v3.6

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la rétrogradation de etcd v3.7 vers v3.6 peut se faire sans interruption de service, par mise à jour progressive :

un à un, arrêtez les processus etcd v3.7 et remplacez-les par des processus etcd v3.6
après avoir activé la remontée de version, les nouvelles fonctionnalités de la v3.7 ne sont plus disponibles pour le cluster

Avant de effectuer une mise vers une version antérieure , lisez le reste du présent guide afin de vous préparer.

Mettre à jour etcd de 3.4 à 3.5

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau de etcd 3.4 vers 3.5 peut être effectuée sans interruption de service, en mode mise à niveau progressive :

un par un, arrêtez les processus etcd v3.4 et remplacez-les par des processus etcd v3.5
après avoir lancé tous les processus v3.5, les nouvelles fonctionnalités de la version v3.5 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Rétrogradation d'etcd de la version 3.5 à la 3.4

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la rétrogradation de etcd 3.5 vers 3.4 peut s’effectuer sans interruption de service, en mode rolling :

un par un, arrêtez les processus etcd 3.5 et remplacez-les par des processus etcd 3.4
après avoir lancé des processus 3.4, les nouvelles fonctionnalités de 3.5 ne sont plus disponibles pour le cluster

Avant de effectuer une mise vers une version antérieure , lisez le reste du présent guide afin de vous préparer.

Rétrogradation d'etcd de la version v3.6 à la v3.5

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la rétrogradation de etcd v3.6 vers v3.5 peut s’effectuer sans interruption de service, en mode rolling :

un à un, arrêtez les processus etcd v3.6 et remplacez-les par des processus etcd v3.5
après avoir activé la rétrogradation, les nouvelles fonctionnalités de la version v3.6 ne sont plus disponibles pour le cluster

Avant de effectuer une mise vers une version antérieure , lisez le reste du présent guide afin de vous préparer.

Mettre à jour etcd de 3.3 à 3.4

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau de etcd 3.3 vers 3.4 peut s’effectuer sans interruption de service, par mise à niveau progressive :

un par un, arrêtez les processus etcd v3.3 et remplacez-les par des processus etcd v3.4
après avoir lancé tous les processus v3.4, les nouvelles fonctionnalités de la version v3.4 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Mettre à jour etcd de la version v3.6 à la version v3.7

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau de etcd v3.6 vers v3.7 peut être une mise à niveau progressive sans interruption de service :

un à un, arrêtez les processus etcd v3.6 et remplacez-les par des processus etcd v3.7
après avoir lancé tous les processus v3.7, les nouvelles fonctionnalités de la version v3.7 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Mettre à jour etcd de 3.2 vers 3.3

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau de etcd 3.2 vers 3.3 peut être effectuée sans interruption de service, par mise à niveau progressive :

un par un, arrêtez les processus etcd v3.2 et remplacez-les par des processus etcd v3.3
après avoir lancé tous les processus v3.3, les nouvelles fonctionnalités de la version v3.3 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Mettre à jour etcd de 3.1 vers 3.2

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau de etcd 3.1 vers 3.2 peut être effectuée sans interruption de service, par mise à niveau progressive :

un par un, arrêtez les processus etcd v3.1 et remplacez-les par des processus etcd v3.2
après avoir lancé tous les processus v3.2, les nouvelles fonctionnalités de la version v3.2 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Mettre à jour etcd de la version 3.0 à la 3.1

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau d’etcd 3.0 vers 3.1 peut être effectuée sans interruption de service, par mise à niveau progressive :

un nœud à la fois, arrêtez les processus etcd v3.0 et remplacez-les par des processus etcd v3.1
après avoir lancé tous les processus v3.1, les nouvelles fonctionnalités de la version v3.1 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Mettre à jour etcd de la version 2.3 à la 3.0

Mon, 01 Jan 0001 00:00:00 +0000

Dans le cas général, la mise à niveau de etcd 2.3 vers 3.0 peut s’effectuer sans interruption de service, par mise à niveau progressive :

un par un, arrêtez les processus etcd v2.3 et remplacez-les par des processus etcd v3.0
après avoir lancé tous les processus v3.0, les nouvelles fonctionnalités de la version 3.0 sont disponibles pour le cluster

Avant de lancer la mise à jour , lisez le reste du présent guide afin de vous préparer.

Guidelines de tri des problèmes

Mon, 01 Jan 0001 00:00:00 +0000

Objectif

Accélérer la gestion des problèmes.

Les problèmes liés à etcd sont répertoriés sur https://github.com/etcd-io/etcd/issues et sont identifiés par des étiquettes. Par exemple, un problème identifié comme un bogue sera éventuellement étiqueté area/bug . Les nouveaux problèmes apparaissent initialement sans étiquette, mais les responsables etcd et les contributeurs actifs ajoutent des étiquettes en fonction de leurs constatations. La liste détaillée des étiquettes est disponible sur https://github.com/kubernetes/kubernetes/labels

Voici quelques recherches prédéfinies sur les problèmes, pour plus de commodité :

Gestion des demandes de tirage

Mon, 01 Jan 0001 00:00:00 +0000

Objectif

Accélérer la gestion des PR.

Les demandes de fusion etcd sont listées sur https://github.com/etcd-io/etcd/pulls Une demande de fusion peut avoir divers étiquettes, un délai d’achèvement, un validateur, etc. La liste détaillée des étiquettes est disponible sur https://github.com/kubernetes/kubernetes/labels

Voici quelques exemples de recherches sur PR pour plus de commodité :

Portée

Ces directives servent de document principal pour la gestion des demandes de tirage (PR) dans etcd. Tous sont invités à aider à la gestion des PR, mais le travail et les responsabilités décrits dans ce document s’adressent principalement aux mainteneurs et contributeurs actifs de etcd.

Attribution et licence

Mon, 01 Jan 0001 00:00:00 +0000

Le fichier pig.center republie la documentation rédigée par six projets amont. Chaque page de documentation comporte une mention d’un seul trait à la fin, indiquant l’œuvre dont elle est issue, son titulaire du droit d’auteur, sa licence, ainsi qu’un lien renvoyant à la section de cette page qui la traite.

Cette page est cet enregistrement. Elle indique ce qui a été importé, à quelle date, à partir de quelle révision verrouillée, selon quelle licence, et où la notice complète du projet amont est conservée.

recherche

Mon, 01 Jan 0001 00:00:00 +0000

Composants communautaires PostgreSQL on PIG.CENTER

Notes de version pgBadger 13.x

v13.2 · 2025-12-29

v13.1 · 2025-03-16

Actualités

pgBackRest 2.59.1 publié

Commande d'annotation (annotate)

Options de commande

Option d’annotation de sauvegarde (--annotation)

Paramètres de configuration dynamique

Paramètres de configuration YAML

Global/Universel

Fonctionnalités

Guide de démarrage

Introduction

Statut de développement

Notes de version de pgBadger 12.x

v12.4 · 2023-12-25

v12.3 · 2023-11-27

Commande d’archive (archive-get)

Configuration : pgbouncer.ini

Description

Paramètres génériques

fichier_journal

Guide utilisateur (Debian/Ubuntu)

Introduction

Installation

Prérequis pour Mac OS

Psycopg

Fundamentaux de la répartition de charge

Téléchargement et installation

Choisissez un canal de distribution

Notes de version de pgBadger 11.x

v11.8 · 2022-04-08

Qu'est-ce qu'HAProxy et comment il fonctionne

Commande de poussée d'archive (archive-push)

Paramètres de configuration de l'environnement

Global/Universel

Journalisation

Guide utilisateur (RHEL)

Introduction

Référence en ligne de commande

Utilisation et options

Usage : pgbouncer commande

Synopsis

Description

Notes de version pgBadger 10.x

v10.3 · 2019-02-14

API REST Patroni

Points de terminaison de vérification de santé

Commande de sauvegarde (backup)

Options de commande

Option d’annotation de sauvegarde (--annotation)

Fonctionnalités de base

3.3.1. Fonctionnalités de base : Proxys

Compilation et installation de PgBouncer

Construction

Configuration de journalisation de PostgreSQL

Journalisation minimale des requêtes

Notes de version de pgBadger 9.x

v9.2 · 2017-07-27

Commande de vérification (check)

Référence de configuration

Introduction

Fonctionnalités standard

3.4.1. Fonctionnalités standard : Échantillonnage et conversion d’informations

patronictl

Configuration

Source Versions Téléchargement

PgBouncer 1.25

PgBouncer 1.24

PgBouncer 1.23

PgBouncer 1.22

PgBouncer 1.21

PgBouncer 1.20

PgBouncer 1.19

PgBouncer 1.18

PgBouncer 1.17

PgBouncer 1.16

PgBouncer 1.15

Option d’annotation de sauvegarde (`--annotation`)

Option d’annotation de sauvegarde (`--annotation`)

Découper un grand fichier avec `-j`

Afficher l’option d’aide (`--help`)