Concept on PIG.CENTER

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.

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.

Documentation Patroni 4.1.5

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

[!AVERTISSEMENT]

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

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

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

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

pgBackRest 2.59.1 Documentation

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

Introduction

pgBackRest est une solution fiable de sauvegarde et de restauration pour PostgreSQL, qui s’adapte sans heurt aux plus grands bases de données et charges de travail.

pgBackRest v2.59.1 est la version stable actuelle. Les notes de version se trouvent sur la page Releases .

Merci de nous donner une étoile sur GitHub si vous appréciez pgBackRest !

Actualités

17 août 2026 - pgBackRest 2.59.1 publié

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.

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

Documentation PgBouncer 1.25.2

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

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.

L’objectif de pgbouncer est de réduire l’impact sur les performances lié à l’ouverture de nouvelles connexions vers PostgreSQL.

Afin de ne pas compromettre la sémantique transactionnelle pour le pooling de connexions, pgbouncer prend en charge plusieurs types de pooling lors de la rotation des connexions :

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 :

pgBadger 13.2 Documentation

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

pgBadger est un analyseur de journaux PostgreSQL rapide et autonome, écrit en Perl. Il lit les journaux PostgreSQL ou PgBouncer et génère des sorties détaillées au format HTML, texte, binaire, JSON ou CSV brut. Les rapports HTML sont autonomes, interactifs, zoomables et nécessitent uniquement un navigateur web pour être visualisés.

Pourquoi pgBadger

pgBadger est conçu pour les gros volumes de journaux et une utilisation opérationnelle :

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.

etcd 3.7 Documentation

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

etcd est un magasin clé-valeur distribué à cohérence forte. Ces guides traitent de l’installation et de l’exploitation d’etcd, de la mise en œuvre d’applications basées sur ses API, de sa conception, de la mesure des performances, ainsi que de la mise à jour ou de la rétrogradation des clusters dans la branche de version 3.7.

Commencez par Démarrage rapide pour un cluster local à membre unique, Installation pour les chemins d’installation pris en charge, ou Guide des opérations pour les déploiements en production.

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.

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.

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

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.

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.

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 :

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.

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.

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 :

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.

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.

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.

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.

Internes

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

Apprentissage

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

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.

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.

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.

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.

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.