Vous trouverez en ligne les différentes versions complètes de ce document. La version imprimée ne contient pas les travaux pratiques. Ils sont présents dans la version numérique (PDF ou HTML).

Vous n’avez pas le droit d’utiliser cette création à des fins commerciales.

Si vous modifiez, transformez ou adaptez cette création, vous n’avez le droit de distribuer la création qui en résulte que sous un contrat identique à celui-ci.

Vous devez citer le nom de l’auteur original de la manière indiquée par l’auteur de l’œuvre ou le titulaire des droits qui vous confère cette autorisation (mais pas d’une manière qui suggérerait qu’ils vous soutiennent ou approuvent votre utilisation de l’œuvre). À chaque réutilisation ou distribution de cette création, vous devez faire apparaître clairement au public les conditions contractuelles de sa mise à disposition. La meilleure manière de les indiquer est un lien vers cette page web. Chacune de ces conditions peut être levée si vous obtenez l’autorisation du titulaire des droits sur cette œuvre. Rien dans ce contrat ne diminue ou ne restreint le droit moral de l’auteur ou des auteurs.

Le texte complet de la licence est disponible sur http://creativecommons.org/licenses/by-nc-sa/2.0/fr/legalcode

Cela inclut les diapositives, les manuels eux-mêmes et les travaux pratiques. Cette formation peut également contenir quelques images et schémas dont la redistribution est soumise à des licences différentes qui sont alors précisées.

Sur les versions précédentes susceptibles d’être encore rencontrées en production, seuls quelques points très importants sont évoqués, en plus éventuellement de quelques éléments historiques.

Sauf précision contraire, le système d’exploitation utilisé est Linux.

La haute disponibilité est un sujet complexe. Plusieurs outils libres coexistent au sein de l’écosystème PostgreSQL, chacun abordant le sujet d’une façon différente.

Ce document clarifie la définition de « haute disponibilité », des méthodes existantes et des contraintes à considérer. L’objectif est d’aider à la prise de décision et le choix de la solution.

Deux critères essentiels permettent de contraindre le choix d’une solution : le RTO (recovery time objectives) et le RPO (recovery point objective).

Le RTO représente la durée maximale d’interruption de service admissible, depuis la coupure de service jusqu’à son rétablissement. Il inclut le délai de détection de l’incident, le délai de prise en charge et le temps de mise en œuvre des actions correctives. Un RTO peut tendre vers zéro mais ne l’atteint jamais parfaitement. Une coupure de service est le plus souvent inévitable, aussi courte soit-elle.

Le RPO représente la durée maximale d’activité de production déjà réalisée que l’on s’autorise à perdre en cas d’incident. Contrairement au RTO, le RPO peut atteindre l’objectif de zéro perte.

Les deux critères sont complémentaires. Ils ont une influence importante sur le choix d’une solution et sur son coût total. Plus les RTO et RPO sont courts, plus la solution est complexe. Cette complexité se répercute directement sur le coût de mise en œuvre, de formation et de maintenance.

Le coût d’une architecture est exponentiel par rapport à sa disponibilité.

La Haute Disponibilité de service définit les moyens techniques mis en œuvre pour garantir une continuité d’activité suite à un incident sur un service.

La haute disponibilité de service nécessite de redonder tous les éléments nécessaires à l’activité du service : l’alimentation électrique, ses accès réseaux, le réseau lui-même, les serveurs, le stockage, les administrateurs, etc.

En plus de cette redondance, une technique de réplication synchrone ou asynchrone est souvent mise en œuvre afin de maintenir à l’identique ou presque les serveurs redondés.

Pour que la disponibilité ne soit pas affectée par le temps de réaction des humains, on peut rechercher à automatiser les bascules vers un serveur sain en cas de problème.

La Haute disponibilité des données définit les moyens techniques mis en œuvre pour garantir une perte faible voire nulle de données en cas d’incident. Ce niveau de disponibilité des données est assuré en redondant les données sur plusieurs systèmes physiques distincts et en assurant que chaque écriture est bien réalisée sur plusieurs d’entre eux.

Dans le cas d’une réplication synchrone entre les systèmes, les écritures sont suspendues tant qu’elles ne peuvent être validées de façon fiable sur au moins deux systèmes.

Par exemple, un RAID 1 fonctionnant sur un seul disque suite à un incident n’est PAS un environnement à haute disponibilité des données, mais à haute disponibilité de service.

La position du curseur entre la haute disponibilité de service et la haute disponibilité de données guide aussi le choix de la solution. S’il est possible d’atteindre le double objectif, l’impact sur les solutions possibles et le coût est une fois de plus important.

Les différentes méthodes de sauvegardes de PostgreSQL (logique avec pg_dump, ou PITR avec pgBackRest ou d’autres outils) sont souvent sous-estimées. Elles sont pourtant un élément essentiel de toute architecture qui est souvent déjà présent. On n’oubliera d’ailleurs pas de tester régulièrement ses sauvegardes.

Investir dans l’optimisation des sauvegardes peut déjà assurer un certain niveau de disponibilité de votre service, à moindre coût.

Quoi qu’il en soit, la sauvegarde est un élément crucial de toute architecture. Ce sujet doit toujours faire partie de la réflexion autour de la disponibilité d’un service.

La sauvegarde PITR (Point In Time Recovery) est une méthode permettant de restaurer une instance PostgreSQL à n’importe quel instant durant la fenêtre de rétention définie, par exemple les dernières 24 heures. Le temps de restauration (RTO) dépend de deux variables : le volume de l’instance et son volume d’écriture.

Avec le bon matériel, les bonnes pratiques et une politique de sauvegarde adaptée, il est possible d’atteindre un RTO de quelques minutes, dans la plupart des cas.

La maîtrise du RPO (perte de données) repose sur la fréquence d’archivage des journaux de transactions. Un RPO d’une minute est tout à fait envisageable. En-dessous, nous entrons dans le domaine de la réplication en streaming, soit vers une instance secondaire, soit avec l’outil pg_receivewal (pour la sauvegarde uniquement). Nous abordons ce sujet dans un futur chapitre.

Il est possible d’utiliser les journaux de transactions archivés dans le cadre de la réplication physique. Ces archives deviennent alors un second canal d’échange entre l’instance primaire et ses secondaires, apportant une redondance à la réplication elle-même.

Parmi les outils existants et éprouvés au sein de la communauté, nous pouvons citer les deux ci-dessus.

Un module de nos formations les traite en détail.

Le principal point faible de la sauvegarde PITR est le temps de prise en compte de l’incident et donc d’intervention d’un administrateur.

Enfin, la sauvegarde PITR doit être surveillée de très près par les équipes d’administration au travers d’une supervision adaptée.

La réplication physique interne de PostgreSQL réplique le contenu des journaux de transactions. Les instances secondaires sont considérées comme des « clones » de l’instance primaire.

Avec peu de configuration préalable, il est possible de créer des instances secondaires directement à partir de l’instance primaire ou en restaurant une sauvegarde PITR.

La mécanique de réplication est très efficace, car elle ne réplique que les modifications binaires effectuées dans les tables et les index.

Cette étape assure déjà une haute disponibilité de données, ces dernières étant présentes sur plusieurs serveurs distincts.

La réplication permet d’atteindre un RPO et un RTO plus faibles que celui d’une simple sauvegarde PITR, au prix d’un investissement plus important (matériel redondant), d’une prix d’investissement plus important (redondance du matériel), d’une complexification de l’architecture et de sa maintenance. Le RTO deviendra également plus lié au temps de réaction qu’à la bascule technique.

PostgreSQL supporte la réplication asynchrone ou synchrone.

La réplication asynchrone autorise un retard entre l’instance primaire et ses secondaires, ce qui implique un RPO supérieur à zéro. Ce retard dépend directement du volume d’écriture envoyé par le primaire et de la capacité du réseau à diffuser ce volume, donc son débit. Une utilisation OLTP a un retard typique inférieur à la seconde. Ce retard peut cependant être plus important lors des périodes de maintenance (VACUUM, REINDEX) ou lors d’écritures en masse de données.

La réplication synchrone s’assure que chaque écriture soit présente sur au moins deux instances avant de valider une transaction. Ce mode permet d’atteindre un RPO de zéro, mais impose d’avoir au minimum trois nœuds dans le cluster, autorisant ainsi la perte complète d’un serveur sans bloquer les écritures. En effet, avec deux nœuds seulement, la disponibilité de données n’est plus assurée : la perte d’un nouveau serveur entraînerait le blocage des écritures qui ne pourraient plus être synchrones.

De plus, le nombre de transactions par seconde dépend directement de la latence du réseau : chaque transaction doit attendre la propagation vers un secondaire et le retour de sa validation.

La réplication seule n’assure pas de disponibilité de service en cas d’incident.

Comme pour les sauvegardes PITR, le RTO dépend principalement du temps de prise en charge et d’analyse de l’incident par un opérateur. Une fois la décision prise, la promotion d’un serveur secondaire en production ne nécessite qu’une commande et ne prend typiquement que quelques secondes.

Reste ensuite à faire converger les connexions applicatives vers la nouvelle instance primaire, ce qui est facilement automatisé.

La réplication nécessite donc au minimum deux serveurs, voire trois en cas de réplication synchrone. À ce coût s’ajoutent plusieurs autres plus ou moins cachés :

• le réseau se doit d’être redondé et fiable surtout en cas de réplication synchrone ;
• la formation des équipes d’administration ;
• la mise en œuvre des procédures de construction et de bascule ;
• une supervision plus fine et maîtrisée par les équipes.

Une bascule automatique lors d’un incident permet de réduire le temps d’indisponibilité d’un service au plus bas, assurant ainsi une haute disponibilité de service.

Néanmoins, automatiser la détection d’incident et la prise de décision de basculer un service est un sujet très complexe, difficile à bien appréhender et maintenir, d’autant plus dans le domaine des SGBD.

Quelle que soit la solution choisie pour détecter les anomalies et déclencher une bascule, celle-ci est toujours très naïve. Contrairement à un opérateur humain, la solution n’a pas de capacité d’analyse et n’a pas accès aux mêmes informations. En cas de non-réponse d’un élément du cluster, il lui est impossible de déterminer dans quel état il se trouve précisément. Sous une charge importante ? Serveur arrêté brutalement ou non ? Réseau coupé ?

Il y a une forte probabilité de split-brain si le cluster se contente d’effectuer une bascule sans se préoccuper de l’ancien primaire. Dans cette situation, deux serveurs se partagent la même ressource (IP ou disque ou SGBD) sans le savoir. Corriger le problème et reconsolider les données est fastidieux et entraîne une indisponibilité plus importante qu’une simple bascule manuelle avec analyse et prise de décision humaine.

Quatre mécaniques permettent de se prémunir plus ou moins d’un split-brain : le fencing, le quorum, le watchdog et le SBD (Storage Based Death). La plupart doivent être combinées pour fonctionner de façon optimale.

Le fencing (clôture) isole un serveur ou une ressource de façon active. Suite à une anomalie, et avant la bascule vers le secours prévu, le composant fautif est isolé afin qu’il ne puisse plus interférer avec la production.

Il existe au moins deux anomalies où le fencing est incontournable. La première concerne le cas d’un serveur qui ne répond plus au cluster. Il est alors impossible de définir quelle est la situation sur le serveur. Est-il encore vivant ? Les ressources sont-elles encore actives ? Ont-elles encore un comportement normal ? Ont-elles encore accès à l’éventuel disque partagé ? Dans cette situation, la seule façon de répondre avec certitude à ces questions est d’éteindre le serveur. L’action définit avec certitude que les ressources y sont toutes inactives.

La seconde anomalie où le fencing est essentiel concerne l’arrêt des ressources. Si le serveur est disponible, communique, mais n’arrive pas à éteindre une ressource (problème technique ou timeout), le fencing permet « d’escalader » l’extinction de la ressource en extinction du serveur complet.

Il est aussi possible d’isoler un serveur d’une ressource. Le serveur n’est pas éteint, mais son accès à certaines ressources cruciales est coupé, l’empêchant ainsi de corrompre le cluster. L’isolation peut concerner l’accès au réseau Ethernet ou à un disque partagé par exemple.

Il existe donc plusieurs techniques pour un fencing, mais il doit toujours être rapide et efficace. Pas de demi-mesures ! Les méthodes les plus connues soit coupent le courant, donc agissent sur l’UPS, ou le PDU ; soit éteignent la machine au niveau matériel via l’IPMI ; soit éteignent la machine virtuelle virtuelle brusquement via son hyperviseur ; soit coupent l’accès au réseau, SAN ou Ethernet.

Par conséquent, cette mécanique nécessite souvent de pouvoir gérer finement les droits d’accès à des opérations d’administration lourdes. C’est le cas par exemple au travers des communautés du protocole SNMP, ou la gestion de droits dans les ESX VMware, les accès au PDU, etc.

La mécanique du quorum attribue à chaque nœud un (ou plusieurs) vote. Le cluster n’a le droit d’héberger des ressources que s’il possède la majorité absolue des voix. Par exemple, un cluster à 3 nœuds requiert 2 votes pour pouvoir démarrer les ressources, 3 pour un cluster à 5 nœuds, etc.

Lorsque qu’un ou plusieurs nœuds perdent le quorum, ceux-ci doivent arrêter les ressources qu’ils hébergent.

Il est conseillé de maintenir un nombre de nœuds impair au sein du cluster, mais plusieurs solutions existent en cas d’égalité (par exemple par ordre d’identifiant, par poids, serveurs « témoins » ou arbitre, etc).

Le quorum permet principalement de gérer les incidents liés au réseau, quand « tout va bien » sur les serveurs eux-mêmes et qu’ils peuvent éteindre leurs ressources sans problème, à la demande.

Dans le cadre de PostgreSQL, il faut porter une attention particulière au moment où des serveurs isolés rejoignent de nouveau le cluster. Si l’instance primaire a été arrêtée par manque de quorum, elle pourrait ne pas se raccrocher correctement au nouveau primaire, voire corrompre ses propres fichiers de données. En effet, il est impossible de déterminer quelles écritures ont eu lieu sur cet ancien primaire entre sa déconnexion du reste du cluster et son arrêt total.

Pacemaker intègre la gestion du quorum et peut aussi utiliser un serveur de gestion de vote appelé corosync-qnetd. Ce dernier est utile en tant que tiers pour gérer le quorum de plusieurs clusters Pacemaker à deux nœuds par exemple.

Patroni repose sur un DCS¹ extérieur, par exemple etcd, pour stocker l’état du serveur et prendre ses décisions. La responsabilité de la gestion du quorum est donc déléguée au DCS, dont l’architecture robuste est conçue pour toujours présenter des données fiables et de référence à ses clients (ici Patroni).

Tous les ordinateurs sont désormais équipés d’un watchdog. Par exemple, sur un ordinateur portable Dell Latitude, nous trouvons :

iTCO_wdt : Intel TCO WatchDog Timer Driver v1.11

Sur un Raspberry Pi modèle B :

bcm2835-wdt 20100000.watchdog : Broadcom BCM2835 watchdog timer

Au besoin, il est aussi possible d’ajouter plusieurs autres watchdog grâce à des cartes PCI par exemple, bien que ce ne soit pas nécessaire dans notre cas.

Concernant les machines virtuelles, une configuration supplémentaire est souvent nécessaire pour avoir accès à un watchdog virtualisé.

En dernier recours, il est possible de demander au noyau Linux lui-même de jouer le rôle de watchdog grâce au module softdog. Néanmoins, cette méthode est moins fiable qu’un watchdog matériel car il nécessite que le système d’exploitation fonctionne toujours correctement et qu’au moins un des CPU soit disponible. Cet article entre plus en détails.

Le principe du watchdog peut être résumé par : « nourris le chien de garde avant qu’il ait faim et te mange ». En pratique, un watchdog est un compte à rebours avant la réinitialisation brutale du serveur. Si ce compte à rebours n’est pas régulièrement ré-armé, le serveur est alors redémarré.

Un watchdog surveille donc passivement un processus et assure que ce dernier est toujours disponible et sain. Dans le cadre d’un cluster en haute disponibilité, le processus rendant compte de sa bonne forme au watchdog est le clusterware.

Notez qu’un watchdog permet aussi de déclencher un self-fencing rapide et fiable en cas de besoin. Il permet par exemple de résoudre rapidement le cas de l’arrêt forcé d’une ressource, déjà présenté dans le chapitre consacré au fencing.

Patroni et Pacemaker sont tous deux capables d’utiliser un watchdog sur chaque nœud. Pour Patroni, il n’est armé que sur l’instance primaire. Pour Pacemaker, il est armé sur tous les nœuds.

Le Storage Base Death est une méthode assez ancienne. Elle utilise un ou plusieurs disques partagés (pour la redondance), montés sur tous les nœuds du cluster à la fois. L’espace nécessaire sur chaque disque est très petit, de l’ordre de quelques mégaoctets pour plusieurs centaines de nœuds (le démon sbd utilise 1 à 4 Mo pour 255 nœuds). Cet espace disque est utilisé comme support de communication entre les nœuds qui y échangent des messages.

Le clusterware peut isoler un nœud en déposant un message poison pill à son attention. Le destinataire s’auto-fence grâce à son watchdog dès qu’il lit le message. De plus, un nœud s’auto-fence aussi s’il n’accède plus au stockage et que Pacemaker ou Corosync indiquent eux aussi une anomalie. Ce comportement défensif permet de s’assurer qu’aucun ordre de self-fencing ne peut se perdre.

Grâce au SBD, le cluster est assuré que le nœud distant peut effectuer son self-fencing soit par perte de son accès au disque partagé, soit par réception du poison pill, soit à cause d’une anomalie qui a empêché le clusterware d’assumer le ré-armement du watchdog.

Un exemple détaillé de mise en œuvre avec sdb est disponible dans la documentation de Suse.

Pacemaker supporte ce type d’architecture. Patroni ne supporte pas SBD mais a un comportement similaire vis-à-vis du DCS. D’une part les nœuds Patroni s’échangent des messages au travers du DCS. De plus, Patroni doit attendre l’expiration du verrou leader avant de pouvoir effectuer une bascule, ce qui est similaire au temps de réaction d’une architecture SBD. Mais surtout, l’instance PostgreSQL est déchue en cas de perte de communication avec le DCS, tout le serveur peut même être éteint si le watchdog est actif et que l’opération est trop longue.

Le fencing seul est suffisant pour mettre en œuvre un cluster fiable, même avec deux nœuds. Sans quorum, il est néanmoins nécessaire de désactiver le service au démarrage du cluster, afin d’éviter qu’un nœud isolé ne redémarre ses ressources locales sans l’aval du reste du cluster.

Notez que plusieurs algorithmes existent pour résoudre ce cas, hors quorum, (par exemple les paramètres two_node, wait_for_all et d’autres de Corosync).

L’utilisation d’un SBD est une alternative intéressante et fiable pour la création d’un cluster à deux nœuds sans fencing actif. Le stockage y joue un peu le rôle du tiers au sein du cluster pour départager quel nœud conserve les ressources en cas de partition réseau. Le seul défaut de SBD par rapport au fencing est le temps d’attente supplémentaire avant de pouvoir considérer que le nœud distant est bien hors service. Attention aussi au stockage partagé sur le même réseau que le cluster. En cas d’incident réseau généralisé, comme chaque machine perd son accès au disque ET aux autres machines via Pacemaker, toutes vont s’éteindre.

Une autre architecture possible est le cumul d’un quorum et du watchdog. Avec une telle configuration, en cas de partition réseau, la partition détenant le quorum attend alors la durée théorique du watchdog (plus une marge) avant de démarrer les ressources perdues. Théoriquement, les nœuds de la partition du cluster perdue sont alors soit redémarrés par leur watchdog, soit sains et ont pu arrêter les ressources normalement. Ce type d’architecture nécessite à minima trois nœuds dans le cluster, ou de mettre en place un nœud témoin, utilisé dans le cadre du quorum uniquement (par exemple corosync QNetd).

Le cluster idéal cumule les avantages du fencing, du quorum et des watchdogs.

Comme nous l’avons vu, Pacemaker dispose de toutes les solutions connues. Reste à trouver la bonne combinaison en fonction des contraintes de l’architecture. Patroni, quant à lui, a une architecture similaire au SBD, mais ne force pas à utiliser le watchdog sur les nœuds. Pour avoir une architecture aussi fiable que possible, il est recommandé de toujours activer le watchdog sur tous les nœuds, au strict minima via softdog.

L’ajout d’un mécanisme de bascule automatique implique quelques contraintes qu’il est important de prendre en compte lors de la prise de décision.

En premier lieu, l’automate chargé d’effectuer la bascule automatique a tout pouvoir sur vos instances PostgreSQL. Toute opération concernant vos instances de près ou de loin doit passer par lui. Il est vital que toutes les équipes soient informées de sa présence afin que toute intervention pouvant impacter le service en tienne compte (mise à jour SAN, coupure, réseau, mise à jour applicative, etc).

Pour pallier ces erreurs humaines, la formation d’une équipe est vitale. La connaissance concernant le cluster doit être partagée par plusieurs personnes afin de toujours être en capacité d’agir en cas d’incident. Notez que même si la bascule automatique fonctionne convenablement, il est fréquent de devoir intervenir dessus dans un second temps afin de revenir à un état nominal (en reconstruisant un nœud, par exemple).

À ce propos, la documentation de l’ensemble des procédures est essentielle. En cas de maintenance planifiée ou d’incident, il faut être capable de réagir vite avec le moins d’improvisation possible. Quelle que soit la solution choisie, assurez-vous d’allouer suffisamment de temps au projet pour expérimenter, tester le cluster et le documenter.

Patroni dispose de plusieurs mécanismes pour reconstruire les instances de manière automatique :

• pg_rewind : qui permet de ramener une instance ayant divergé à un point précédent la promotion.
• la suppression automatique du répertoire de données de l’instance quand le pg_rewind échoue ou qu’une instance reste bloquée sur une ancienne timeline. Cette suppression va provoquer une réinitialisation de l’instance. Elle empêche l’utilisation d’une restauration par delta, ce qui peut provoquer une longue indisponibilité sur des volumétries importantes.

Ce module est une introduction à Patroni. Il permet de découvrir quels sont ses pré-requis, les différents éléments nécessaires, leur rôle et leurs interactions.

Les prochains chapitres abordent Patroni lui-même, son rapport avec la réplication PostgreSQL et sa dépendance à un DCS.

Patroni est un gestionnaire de cluster PostgreSQL, capable d’en assurer la haute disponibilité de service. Il maintient l’agrégat en condition opérationnelle, le supervise et provoque une bascule automatique en cas d’incident.

Patroni est en réalité lui-même un agrégat : chaque instance PostgreSQL du cluster est contrôlée par son propre démon patroni, écrit en python. Tous ces démons surveillent les évènements au sein de l’agrégat et coopèrent pour maintenir le service disponible.

Chaque démon patroni a la responsabilité de créer, configurer, démarrer, superviser, arrêter, promouvoir ou rétrograder son instance locale, en fonction des évènements détectés au sein du cluster.

L’application des modifications de la configuration de PostgreSQL est effectuée par Patroni qui se charge de la répercuter sur tous les nœuds.

Patroni se base sur la réplication physique native de PostgreSQL pour assurer la haute disponibilité des données. Maîtrisant la création et configuration des instances, il est capable d’assurer automatiquement la mise en œuvre de cette réplication.

Patroni configure et maintient cette réplication physique en mode synchrone ou asynchrone, avec ou sans cascade de réplication, en fonction de la configuration demandée.

Suite à une bascule, il reconfigure automatiquement les secondaires afin que ceux-ci se reconnectent au nouveau primaire.

Optionnellement, il est aussi capable de resynchroniser un ancien primaire en tant que secondaire suite à un incident.

Pour effectuer ces différentes opérations, il s’appuie sur des outils fournis avec PostgreSQL comme pg_basebackup et pg_rewind pour construire ou reconstruire une instance secondaire. Mais cette capacité est encore étendue grâce à la possibilité d’utiliser des outils de la communauté comme barman, pgbackrest ou wal-g.

Les démons patroni s’appuient sur un stockage de données distribué (DCS, Distributed Consensus Store²) pour partager l’état des nœuds et leur configuration au sein du cluster.

Par exemple les processus Patroni y écrivent lequel d’entre eux est le leader, pouvant héberger l’instance primaire PostgreSQL. Ils reposent sur les fonctionnalités du DCS qui assurent des écritures atomiques et homogènes au sein du cluster, empêchant toute race condition et donc que les démons patroni ne voient des valeurs différentes.

Le DCS est la « source de vérité » du cluster, le notaire arbitrant de façon fiable et officielle le leader du cluster. Les processus patroni lui font entièrement confiance et respectent scrupuleusement les informations qu’ils y trouvent.

À tel point que par défaut, si le leader Patroni ne peut plus joindre le DCS, il rétrograde immédiatement son instance locale en secondaire. Si cette opération échoue ou est trop longue, il est même capable de déclencher un reset du serveur.

Le but étant la haute disponibilité, le DCS ne doit pas devenir un SPoF (single point of failure). Il doit donc lui aussi être déployé en agrégat afin d’assurer une tolérance aux pannes et une disponibilité maximale du service.

Patroni supporte plusieurs DCS différents, s’adaptant ainsi au mieux à l’environnement dans lequel il est déployé. En voici une liste à titre indicatif : etcd (v2 ou v3), Consul, Zookeeper, Exhibitor et Kubernetes.

Ce schéma présente les deux types d’agrégats :

• un unique agrégat de trois serveurs minimum héberge les démons DCS ;
• plusieurs agrégats PostgreSQL indépendants hébergent les démons patroni et leur instance PostgreSQL respective (2 instances minimum).

Ces clusters ont des outils, procédures et maintenances différentes qu’il faut comprendre en détail, documenter et superviser. Différents modules de formation abordent chacun des services de cette architecture :

• un module de rappel concernant la réplication de PostgreSQL ;
• un module dédié au DCS etcd ;
• un module dédié à Patroni lui-même.

Patroni configure la réplication physique native de PostgreSQL pour assurer la redondance des données au sein de l’agrégat. Il est important de bien maîtriser comment cette réplication fonctionne.

Effectivement, Patroni ayant pour but d’optimiser la disponibilité, l’administrateur doit être lui-même réactif et identifier rapidement les causes d’un incident ou d’un problème de réplication, savoir ré-intégrer un nœud en réplication, etc. Et ce, sans créer de sur-incident bien entendu.

Le serveur PostgreSQL secondaire lance un processus appelé walreceiver, dont le but est de se connecter au serveur primaire et d’attendre les modifications de la réplication.

Le walreceiver a donc besoin de se connecter sur le serveur PostgreSQL primaire. Ce dernier doit être configuré pour accepter cette connexion. Quand elle est acceptée par le serveur primaire, le serveur PostgreSQL du serveur primaire lance un nouveau processus, appelé walsender. Ce dernier a pour but d’envoyer les données de réplication au serveur secondaire. Les données de réplication sont envoyées suivant l’activité et certains paramètres de configuration.

Cette méthode permet une réplication plus proche du serveur primaire que le log shipping. On peut même configurer un mode synchrone : un client du serveur primaire ne récupère pas la main tant que ses modifications ne sont pas enregistrées sur le serveur primaire et sur le serveur secondaire synchrone. Cela s’effectue à la validation de la transaction, implicite ou lors d’un COMMIT.

Enfin, la réplication en cascade permet à un secondaire de fournir les informations de réplication à un autre secondaire, déchargeant ainsi le serveur primaire d’un certain travail et diminuant aussi la bande passante réseau utilisée par le serveur primaire.

Il faut tout d’abord s’assurer que PostgreSQL enregistre suffisamment d’informations pour que le serveur secondaire puisse rejouer toutes les modifications survenant sur le serveur primaire. Dans certains cas, PostgreSQL peut économiser l’écriture de journaux quand cela ne pose pas de problème pour l’intégrité des données en cas de crash. Par exemple, sur une instance sans archivage ni réplication, il est inutile de tracer la totalité d’une transaction qui commence par créer une table, puis qui la remplit. En cas de crash pendant l’opération, l’opération complète est annulée, la table n’existera plus : PostgreSQL peut donc écrire directement son contenu sur le disque sans journaliser.

Cependant, pour restaurer cette table ou la répliquer, il est nécessaire d’avoir les étapes intermédiaires (le contenu de la table) et il faut donc écrire ces informations supplémentaires dans les journaux.

Le paramètre wal_level fixe le comportement à adopter. Comme son nom l’indique, il permet de préciser le niveau d’informations que l’on souhaite avoir dans les journaux. Il connaît trois valeurs :

• Le niveau replica est adapté à l’archivage ou la réplication, en plus de la sécurisation contre les arrêts brutaux. C’est le niveau par défaut. L’optimisation évoquée plus haut n’est pas possible.
• Le niveau minimal n’offre que la protection contre les arrêts brutaux, mais ne permet ni réplication ni sauvegarde PITR. Ce niveau ne sert plus guère qu’aux environnements ni archivés, ni répliqués, pour réduire la quantité de journaux générés, comme dans l’optimisation ci-dessus.
• Le niveau logical est le plus complet et doit être activé pour l’utilisation du décodage logique, notamment pour utiliser la réplication logique. Il n’est pas nécessaire pour la sauvegarde PITR ou la réplication physique, ni incompatible.

Le serveur primaire accepte un nombre maximum de connexions de réplication : il s’agit du paramètre max_wal_senders. Il faut compter au moins une connexion pour chaque serveur secondaire susceptible de se connecter, ou les outils utilisant le streaming comme pg_basebackup ou pg_receivewal. Il est conseillé de prévoir « large » d’entrée : l’impact mémoire est négligeable, et cela évite d’avoir à redémarrer l’instance primaire à chaque modification. La valeur par défaut de 10 devrait suffire dans la plupart des cas.

Le paramètre wal_sender_timeout permet de couper toute connexion inactive après le délai indiqué par ce paramètre. Par défaut, le délai est d’une minute. Cela permet au serveur primaire de ne pas conserver une connexion coupée ou dont le client a disparu pour une raison ou une autre. Le secondaire retentera par la suite une connexion complète.

Il est nécessaire après cela de configurer le fichier pg_hba.conf. Dans ce fichier, une ligne (par secondaire) doit indiquer les connexions de réplication. L’idée est d’éviter que tout le monde puisse se connecter pour répliquer l’intégralité des données.

Pour distinguer une ligne de connexion standard et une ligne de connexion de réplication, la colonne indiquant la base de données doit contenir le mot « replication ». Par exemple :

host   replication   user_repli   10.0.0.2/32   scram-sha-256

Dans ce cas, l’utilisateur user_repli pourra entamer une connexion de réplication vers le serveur primaire à condition que la demande de connexion provienne de l’adresse IP 10.0.0.2 et que cette demande de connexion précise le bon mot de passe au format scram-sha-256.

Un utilisateur dédié à la réplication est conseillé pour des raisons de sécurité. On le créera avec les droits suivants :

CREATE ROLE user_repli LOGIN REPLICATION ;

et bien sûr un mot de passe complexe.

Les connexions locales de réplication sont autorisées par défaut sans mot de passe.

Après modification du fichier postgresql.conf et du fichier pg_hba.conf, il est temps de demander à PostgreSQL de recharger sa configuration. L’action reload suffit dans tous les cas, sauf celui où max_wal_senders est modifié (auquel cas il faudra redémarrer PostgreSQL).

La première action à réaliser ressemble beaucoup à ce que propose la sauvegarde en ligne des fichiers. Il s’agit de copier le répertoire des données de PostgreSQL ainsi que les tablespaces associés.

pg_basebackup :

L’outil le plus simple est pg_basebackup. Ses avantages sont sa disponibilité et sa facilité d’utilisation. Il sait ce qu’il n’y a pas besoin de copier et peut inclure les journaux nécessaires pour ne pas avoir à paramétrer l’archivage.

Il peut utiliser la connexion de réplication déjà prévue pour le secondaire, poser des slots temporaires ou le slot définitif.

Pour faciliter la mise en place d’un secondaire, il peut générer les fichiers de configuration à partir des paramètres qui lui ont été fournis (option --write-recovery-conf).

Malgré beaucoup d’améliorations dans les dernières versions, la limite principale de pg_basebackup reste d’exiger un répertoire cible vide : on doit toujours recopier l’intégralité de la base copiée. Cela peut être pénible lors de tests répétés avec une grosse base, ou avec une liaison instable.

Outils PITR :

L’idéal est un outil de restauration PITR permettant la restauration en mode delta, par exemple pgBackRest avec l’option --delta. Ne sont restaurés que les fichiers ayant changé, et le primaire n’est pas chargé par la copie.

rsync :

Rappelons les trois étapes essentielles :

• le pg_backup_start() ;
• la copie des fichiers : généralement avec rsync --whole-file, ou tout moyen permettant une copie fiable et rapide ;
• le pg_backup_stop().

On exclura les fichiers inutiles lors de la copie qui pourraient gêner un redémarrage, notamment le fichier postmaster.pid et les répertoires pg_wal, pg_replslot, pg_dynshmem, pg_notify, pg_serial, pg_snapshots, pg_stat_tmp, pg_subtrans, pgslq_tmp*. La liste complète figure dans la documentation officielle.

Au choix, les paramètres sont à ajouter dans postgresql.conf, dans un fichier appelé par ce dernier avec une clause d’inclusion, ou dans postgresql.auto.conf (forcément dans le répertoire de données pour ce dernier, et qui surcharge les fichiers précédents). Cela dépend des habitudes, de la méthode d’industrialisation…

S’il y a des paramètres propres au primaire dans la configuration d’un secondaire, ils seront ignorés, et vice-versa. Dans les cas simples, le postgresql.conf peut donc être le même.

Puis il faut créer un fichier vide nommé standby.signal dans le répertoire PGDATA, qui indique à PostgreSQL que le serveur doit rester en recovery permanent.

PostgreSQL doit aussi savoir comment se connecter au serveur primaire. C’est le paramètre primary_conninfo qui le lui dit. Il s’agit d’un DSN standard où il est possible de spécifier l’adresse IP de l’hôte ou son alias, le numéro de port, le nom de l’utilisateur, etc. Il est aussi possible de spécifier le mot de passe, mais c’est risqué en terme de sécurité. En effet, PostgreSQL ne vérifie pas si ce fichier est lisible par quelqu’un d’autre que lui. Il est donc préférable de placer le mot de passe dans le fichier .pgpass, généralement dans ~postgres/ sur le secondaire, fichier qui n’est utilisé que s’il n’est lisible que par son propriétaire. Par exemple :

primary_conninfo = 'user=postgres host=prod passfile=/var/lib/postgresql/.pgpass'

Toutes les options de la libpq sont accessibles. Par exemple, cette chaîne de connexion a été générée pour un nouveau secondaire par pg_basebackup -R :

primary_conninfo = 'host=prod user=postgres passfile=''/var/lib/postgresql/.pgpass'' channel_binding=prefer port=5436 sslmode=prefer sslcompression=0 sslcertmode=allow sslsni=1 ssl_min_protocol_version=TLSv1.2 gssencmode=prefer krbsrvname=postgres gssdelegation=0 target_session_attrs=any load_balance_hosts=disable

S’y trouvent beaucoup de paramétrage par défaut dépendant de méthodes d’authentification, ou pour le SSL.

Parmi les autres paramètres optionnels de primary_conninfo, il est conseillé d’ajouter application_name, par exemple avec le nom du serveur. Cela facilite la supervision. C’est même nécessaire pour paramétrer une réplication synchrone.

primary_conninfo = 'user=postgres host=prod passfile=/var/lib/postgresql/.pgpass  application_name=secondaire2 '

Si application_name n’est pas fourni, le cluster_name du secondaire sera utilisé, mais il est rarement correctement configuré (par défaut, il vaut 16/main sur Debian/Ubuntu, et n’est pas configuré sur Red Hat/Rocky Linux).

De manière optionnelle, nous verrons que l’on peut définir aussi deux paramètres :

• primary_slot_name, pour sécuriser la réplication avec un slot de réplication ;
• restore_command, pour sécuriser la réplication avec un accès à la sauvegarde PITR.

Le paramètre wal_receiver_timeout sur le secondaire est le symétrique de wal_sender_timeout sur le primaire. Il indique au bout de combien de temps couper une connexion inactive. Le secondaire retentera la connexion plus tard.

Il ne reste plus qu’à démarrer le serveur secondaire.

En cas de problème, le premier endroit où aller chercher est bien entendu le fichier de trace postgresql.log.

Sur le primaire, un processus walsender apparaît pour chaque secondaire connecté. Son nom de processus est mis à jour en permanence avec l’emplacement dans le flux de journaux de transactions :

 postgres: 16/secondaire1: walsender postgres [local] streaming 15/6A6EF408
 postgres: 16/secondaire2: walsender postgres [local] streaming 15/6A6EF408

Symétriquement, sur chaque secondaire, un process walreceiver apparaît.

 postgres: 16/secondaire2: walreceiver streaming 0/DD73C218

La pire chose qui puisse arriver lors d’une bascule est d’avoir les deux serveurs, ancien primaire et nouveau primaire promu, ouverts tous les deux en écriture. Les applications risquent alors d’écrire dans l’un ou l’autre…

Quelques histoires « d’horreur » à ce sujet :

• de nombreux exemples sur diverses technologies de réplication ;
• post mortem d’un gros problème chez Github en 2018.

Avant une bascule, il est capital de vérifier que toutes les modifications envoyées par le primaire sont arrivées sur le secondaire. Si le primaire a été arrêté proprement, ce sera le cas. Après un CHECKPOINT sur le secondaire, on y retrouvera le même emplacement dans les journaux de transaction.

Ce contrôle doit être systématique avant une bascule. Même si toutes les écritures applicatives sont stoppées sur le primaire, quelques opérations de maintenance peuvent en effet écrire dans les journaux et provoquer un écart entre les deux serveurs (divergence). Il n’y aura alors pas de perte de données mais cela pourrait gêner la transformation de l’ancien primaire en secondaire, par exemple.

Noter que pg_controldata n’est pas dans les chemins par défaut des distributions. La fonction SQL pg_control_checkpoint() affiche les même informations, mais n’est bien sûr pas accessible sur un primaire arrêté.

Il existe plusieurs méthodes pour promouvoir un serveur PostgreSQL en mode standby. Les méthodes les plus appropriées sont :

• l’action promote de l’outil pg_ctl, ou de son équivalent dans les scripts des paquets d’installation, comme pg_ctlcluster sous Debian ;
• la fonction SQL pg_promote.

Ces deux méthodes remplacent le fichier de déclenchement historique (trigger file), défini par le paramètre promote_trigger_file, qui n’existe plus à partir de PostgreSQL 16. Dans les versions précédentes, un serveur secondaire vérifie en permanence si ce fichier existe. Dès qu’il apparaît, l’instance est promue. Par mesure de sécurité, il est préconisé d’utiliser un emplacement accessible uniquement aux administrateurs.

La promotion se déroule en bonne partie comme un recovery après restauration PITR.

Une fois l’instance promue, elle finit de rejouer les derniers journaux de transaction en provenance du serveur principal en sa possession, puis se déconnecte de celui-ci (si l’on est encore connecté en streaming).

Le dernier journal reçu de l’ancien primaire est souvent incomplet. Il est renommé avec le suffixe .partial et archivé. Cela évite un conflit de nom éventuel avec le même fichier issu de l’ancien serveur, qui a pu aussi être archivé, à un point éventuellement postérieur à la divergence.

Ensuite, l’instance choisit une nouvelle timeline pour son journal de transactions. Rappelons que la timeline est le premier numéro dans le nom du segment (fichier WAL) ; par exemple une timeline 5 pour un fichier nommé 000000050000003200000031). Le nouveau primaire choisit généralement le numéro suivant celui du primaire (à moins que les archives ne contiennent d’autres timelines de numéro supérieur, s’il y a eu plusieurs restaurations et retours en arrière, et il choisit alors le numéro suivant la dernière).

Le choix d’une nouvelle timeline permet à PostgreSQL de rendre les journaux de transactions de ce nouveau serveur en écriture incompatibles avec son ancien serveur principal. De plus, des journaux de nom différent permet l’archivage depuis ce primaire sans perturber l’ancien s’il existe encore. Il n’y a plus de fichier en commun même si l’espace d’archivage est partagé.

recovery_target_timeline = latest

L’instance crée un fichier d’historique dans pg_wal/, par exemple 00000006.history pour la nouvelle timeline 6. C’est un petit fichier texte qui contient les différentes timelines ayant mené à la nouvelle. Ce fichier est immédiatement archivé s’il y a archivage.

Enfin, l’instance autorise les connexions en lecture et en écriture.

Il n’y a aucune opération obligatoire après une promotion. Cependant, il est conseillé d’exécuter un VACUUM ou un ANALYZE pour que PostgreSQL mette à jour les estimations de nombre de lignes vivantes et mortes. Ces estimations sont utilisées par l’autovacuum pour lutter contre la fragmentation des tables et mettre à jour les statistiques sur les données. Or ces estimations faisant partie des statistiques d’activité, elles ne sont pas répliquées vers les secondaires. Il est donc intéressant de les mettre à jour après une promotion.

Si un serveur secondaire est momentanément indisponible mais revient en ligne sans perte de données (réseau coupé, problème OS…), alors il a de bonnes chances de se « raccrocher » à son serveur primaire. Il faut bien sûr que l’ensemble des journaux de transaction depuis son arrêt soit accessible à ce serveur, sans exception.

En cas de réplication par streaming : le primaire ne doit pas avoir recyclé les journaux après ses checkpoints. Il les aura conservés s’il y a un slot de réplication actif dédié à ce secondaire, ou si on a monté wal_keep_size (ou wal_keep_segments jusque PostgreSQL 12 compris) assez haut par rapport à l’activité en écriture sur le primaire. Les journaux seront alors toujours disponibles sur le principal et le secondaire rattrapera son retard par streaming. Si le primaire n’a plus les journaux, il affichera une erreur, et le secondaire tentera de se rabattre sur le log shipping, s’il est aussi configuré.

En cas de réplication par log shipping, il faut que la restore_command fonctionne, que le stock des journaux remonte assez loin dans le temps (jusqu’au moment où le secondaire a perdu contact), et qu’aucun journal ne manque ou ne soit corrompu. Sinon le secondaire se bloquera au dernier journal chargé. En cas d’échec, ou si le dernier journal disponible vient d’être rejoué, le secondaire basculera sur le streaming, s’il est configuré.

Si le secondaire ne peut rattraper le flux des journaux du primaire, il doit être reconstruit par l’une des méthodes précédentes.

Un secondaire qui a bien « accroché » son primaire se synchronise automatiquement avec lui, que ce soit par streaming ou log shipping. C’est notamment le cas si l’on vient de le construire depuis une sauvegarde ou avec pg_basebackup, et que l’archivage ou le streaming alimentent correctement le secondaire. Cependant, il y a des cas où un secondaire ne peut être simplement raccroché à un primaire, notamment si le secondaire se croit plus avancé que le primaire dans le flux des journaux.

Le cas typique est un ancien primaire que l’on veut transformer en secondaire d’un ancien secondaire promu. Si la bascule s’était faite proprement, et que l’ancien primaire avait pu envoyer tous ses journaux avant de s’arrêter ou d’être arrêté, il n’y a pas de problème. Si le primaire a été arrêté violemment, sans pouvoir transmettre tous ses journaux, l’ancien secondaire n’a rejoué que ce qu’il a reçu, puis a ouvert en écriture sa propre timeline depuis un point moins avancé que là où le primaire était finalement arrivé avant d’être arrêté. Les deux serveurs ont donc « divergé », même pendant très peu de temps. Les journaux non envoyés au nouveau primaire doivent être considérés comme perdus. Quand l’ancien primaire revient en ligne, parfois très longtemps après, il voit que sa timeline est plus avancée que la version qu’en a gardée le nouveau primaire. Il ne sait donc pas comment appliquer les journaux qu’il reçoit du nouveau primaire.

La principale solution, et la plus simple, reste alors la reconstruction du secondaire à raccrocher.

L’utilisation de pg_basebackup est possible mais déconseillée si la volumétrie est importante : cet outil impose une copie de l’ensemble des données du serveur principal, et ce peut être long.

La durée de reconstruction des secondaires peut être optimisée en utilisant des outils de synchronisation de fichiers pour réduire le volume des données à transférer. Les outils de restauration PITR offrent souvent une restauration en mode delta (notamment l’option --delta de pgBackRest) et c’est ce qui est généralement à privilégier. Dans un script de sauvegarde PITR, rsync --whole-file reste une bonne option.

Le fait de disposer de l’ensemble des fichiers de configuration sur tous les nœuds permet de gagner un temps précieux lors des phases de reconstruction, qui peuvent également être scriptées.

Par contre, les opérations de reconstructions se doivent d’être lancées manuellement pour éviter tout risque de corruption de données dues à des opérations automatiques externes, comme lors de l’utilisation de solutions de haute disponibilité.

Enfin, on rappelle qu’il ne faut pas oublier de prendre en compte les tablespaces lors de la reconstruction.

Une alternative à la reconstruction est l’utilisation de l’outil pg_rewind pour « rembobiner » l’ancien primaire, si tous les journaux nécessaires sont disponibles.

La robustesse de la réplication physique est éprouvée depuis longtemps. C’est à cette base solide que Patroni amène l’automatisation de :

• l’ajout de nœuds supplémentaires ;
• la promotion automatique en fonction du nœud ;
• le raccrochage d’un ancien primaire au nouveau primaire.

Ces mécanismes sont abordé dans le module consacré à Patroni.

L’installation est détaillée ici pour Rocky Linux 8 et 9 (similaire à Red Hat et à d’autres variantes comem Oracle Linux et Fedora), et Debian/Ubuntu.

Elle ne dure que quelques minutes.

Sur Rocky Linux 8 ou 9

Installation du dépôt communautaire  :

Les dépôts de la communauté sont sur https://yum.postgresql.org/. Les commandes qui suivent sont inspirées de celles générées par l’assistant sur https://www.postgresql.org/download/linux/redhat/, en précisant :

• la version majeure de PostgreSQL (ici la 16) ;
• la distribution (ici Rocky Linux 8) ;
• l’architecture (ici x86_64, la plus courante).

Les commandes sont à lancer sous root :

# dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms\
/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm

# dnf -qy module disable postgresql

Installation de PostgreSQL 16 (client, serveur, librairies, extensions) : 

# dnf install -y postgresql16-server postgresql16-contrib

Les outils clients et les librairies nécessaires seront automatiquement installés.

Une fonctionnalité avancée optionnelle, le JIT (Just In Time compilation), nécessite un paquet séparé.

# dnf install postgresql16-llvmjit

Création d’une première instance :

Il est conseillé de déclarer PG_SETUP_INITDB_OPTIONS, notamment pour mettre en place les sommes de contrôle et forcer les traces en anglais :

# export PGSETUP_INITDB_OPTIONS='--data-checksums --lc-messages=C'
# /usr/pgsql-16/bin/postgresql-16-setup initdb
# cat /var/lib/pgsql/16/initdb.log

Ce dernier fichier permet de vérifier que tout s’est bien passé et doit finir par :

Success. You can now start the database server using:

    /usr/pgsql-16/bin/pg_ctl -D /var/lib/pgsql/16/data/ -l logfile start

Chemins :

Configuration :

Modifier postgresql.conf est facultatif pour un premier lancement.

Commandes d’administration habituelles :

Démarrage, arrêt, statut, rechargement à chaud de la configuration, redémarrage :

# systemctl start postgresql-16
# systemctl stop postgresql-16
# systemctl status postgresql-16
# systemctl reload postgresql-16
# systemctl restart postgresql-16

Test rapide de bon fonctionnement et connexion à psql :

# systemctl --all |grep postgres
# sudo -iu postgres psql

Démarrage de l’instance au lancement du système d’exploitation :

# systemctl enable postgresql-16

Ouverture du firewall pour le port 5432 :

Voir si le firewall est actif :

# systemctl status firewalld

Si c’est le cas, autoriser un accès extérieur :

# firewall-cmd --zone=public --add-port=5432/tcp --permanent
# firewall-cmd --reload
# firewall-cmd --list-all

(Rappelons que listen_addresses doit être également modifié dans postgresql.conf.)

Création d’autres instances :

Si des instances de versions majeures différentes doivent être installées, il faut d’abord installer les binaires pour chacune (adapter le numéro dans dnf install …) et appeler le script d’installation de chaque version. l’instance par défaut de chaque version vivra dans un sous-répertoire numéroté de /var/lib/pgsql automatiquement créé à l’installation. Il faudra juste modifier les ports dans les postgresql.conf pour que les instances puissent tourner simultanément.

Si plusieurs instances d’une même version majeure (forcément de la même version mineure) doivent cohabiter sur le même serveur, il faut les installer dans des PGDATA différents.

• Ne pas utiliser de tiret dans le nom d’une instance (problèmes potentiels avec systemd).
• Respecter les normes et conventions de l’OS : placer les instances dans un nouveau sous-répertoire de /var/lib/pgsqsl/16/ (ou l’équivalent pour d’autres versions majeures).

Pour créer une seconde instance, nommée par exemple infocentre :

• Création du fichier service de la deuxième instance :

# cp /lib/systemd/system/postgresql-16.service \
        /etc/systemd/system/postgresql-16-infocentre.service

• Modification de ce dernier fichier avec le nouveau chemin :

Environment=PGDATA=/var/lib/pgsql/16/infocentre

• Option 1 : création d’une nouvelle instance vierge :

# export PGSETUP_INITDB_OPTIONS='--data-checksums --lc-messages=C'
# /usr/pgsql-16/bin/postgresql-16-setup initdb postgresql-16-infocentre

• Option 2 : restauration d’une sauvegarde : la procédure dépend de votre outil.

• Adaptation de /var/lib/pgsql/16/infocentre/postgresql.conf (port surtout).

• Commandes de maintenance de cette instance :

# systemctl [start|stop|reload|status] postgresql-16-infocentre
# systemctl [enable|disable] postgresql-16-infocentre

• Ouvrir le nouveau port dans le firewall au besoin.

Sur Debian / Ubuntu

Sauf précision, tout est à effectuer en tant qu’utilisateur root.

Référence : https://apt.postgresql.org/

Installation du dépôt communautaire :

L’installation des dépôts du PGDG est prévue dans le paquet Debian :

# apt update
# apt install -y  gnupg2  postgresql-common 
# /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh

Ce dernier ordre créera le fichier du dépôt /etc/apt/sources.list.d/pgdg.list adapté à la distribution en place.

Installation de PostgreSQL 16 :

La méthode la plus propre consiste à modifier la configuration par défaut avant l’installation :

Dans /etc/postgresql-common/createcluster.conf, paramétrer au moins les sommes de contrôle et les traces en anglais :

initdb_options = '--data-checksums --lc-messages=C'

Puis installer les paquets serveur et clients et leurs dépendances :

# apt install postgresql-16 postgresql-client-16

La première instance est automatiquement créée, démarrée et déclarée comme service à lancer au démarrage du système. Elle porte un nom (par défaut main).

Elle est immédiatement accessible par l’utilisateur système postgres.

Chemins :

Configuration

Modifier postgresql.conf est facultatif pour un premier essai.

Démarrage/arrêt de l’instance, rechargement de configuration :

Debian fournit ses propres outils, qui demandent en paramètre la version et le nom de l’instance :

# pg_ctlcluster 16 main [start|stop|reload|status|restart]

Démarrage de l’instance avec le serveur :

C’est en place par défaut, et modifiable dans /etc/postgresql/16/main/start.conf.

Ouverture du firewall :

Debian et Ubuntu n’installent pas de firewall par défaut.

Statut des instances du serveur :

# pg_lsclusters

Test rapide de bon fonctionnement et connexion à psql :

# systemctl --all |grep postgres
# sudo -iu postgres psql

Destruction d’une instance :

# pg_dropcluster 16 main

Création d’autres instances :

Ce qui suit est valable pour remplacer l’instance par défaut par une autre, par exemple pour mettre les checksums en place :

• optionnellement, /etc/postgresql-common/createcluster.conf permet de mettre en place tout d’entrée les checksums, les messages en anglais, le format des traces ou un emplacement séparé pour les journaux :

initdb_options = '--data-checksums --lc-messages=C'
log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h '
waldir = '/var/lib/postgresql/wal/%v/%c/pg_wal'

• créer une instance :

# pg_createcluster 16 infocentre

Il est également possible de préciser certains paramètres du fichier postgresql.conf, voire les chemins des fichiers (il est conseillé de conserver les chemins par défaut) :

# pg_createcluster 16 infocentre \
  --port=12345 \
  --datadir=/PGDATA/16/infocentre \
  --pgoption shared_buffers='8GB' --pgoption work_mem='50MB' \
  --  --data-checksums --waldir=/ssd/postgresql/16/infocentre/journaux

• adapter au besoin /etc/postgresql/16/infocentre/postgresql.conf ;

• démarrage :

# pg_ctlcluster 16 infocentre start

Accès à l’instance depuis le serveur même (toutes distributions)

Par défaut, l’instance n’est accessible que par l’utilisateur système postgres, qui n’a pas de mot de passe. Un détour par sudo est nécessaire :

$ sudo -iu postgres psql
psql (16.0)
Type "help" for help.
postgres=#

Ce qui suit permet la connexion directement depuis un utilisateur du système :

Pour des tests (pas en production !), il suffit de passer à trust le type de la connexion en local dans le pg_hba.conf :

local   all             postgres                               trust

La connexion en tant qu’utilisateur postgres (ou tout autre) n’est alors plus sécurisée :

dalibo:~$ psql -U postgres
psql (16.0)
Type "help" for help.
postgres=#

Une authentification par mot de passe est plus sécurisée :

• dans pg_hba.conf, paramétrer une authentification par mot de passe pour les accès depuis localhost (déjà en place sous Debian) :

# IPv4 local connections:
host    all             all             127.0.0.1/32            scram-sha-256
# IPv6 local connections:
host    all             all             ::1/128                 scram-sha-256

(Ne pas oublier de recharger la configuration en cas de modification.)

• ajouter un mot de passe à l’utilisateur postgres de l’instance :

dalibo:~$ sudo -iu postgres psql
psql (16.0)
Type "help" for help.
postgres=# \password
Enter new password for user "postgres":
Enter it again:
postgres=# quit

dalibo:~$ psql -h localhost -U postgres
Password for user postgres:
psql (16.0)
Type "help" for help.
postgres=#

• Pour se connecter sans taper le mot de passe à une instance, un fichier .pgpass dans le répertoire personnel doit contenir les informations sur cette connexion :

localhost:5432:*:postgres:motdepassetrèslong

Ce fichier doit être protégé des autres utilisateurs :

$ chmod 600 ~/.pgpass

• Pour n’avoir à taper que psql, on peut définir ces variables d’environnement dans la session voire dans ~/.bashrc :

export PGUSER=postgres
export PGDATABASE=postgres
export PGHOST=localhost

Rappels :

• en cas de problème, consulter les traces (dans /var/lib/pgsql/16/data/log ou /var/log/postgresql/) ;
• toute modification de pg_hba.conf ou postgresql.conf impliquant de recharger la configuration peut être réalisée par une de ces trois méthodes en fonction du système :

root:~# systemctl reload postgresql-16

root:~# pg_ctlcluster 16 main reload

postgres:~$ psql -c 'SELECT pg_reload_conf()'

• Créer l’instance principale dans /var/lib/pgsql/16/main sur le serveur p1.

• Mettre en place la configuration de la réplication par streaming.
• L’utilisateur dédié sera nommé repli.

• Créer la première instance secondaire sur le serveur p2, par copie à chaud du répertoire de données.

• Démarrer la nouvelle instance sur p2 et s’assurer que la réplication fonctionne bien avec ps.
• Tenter de se connecter au serveur secondaire.
• Créer quelques tables pour vérifier que les écritures se propagent du primaire au secondaire.

• En respectant les étapes de vérification de l’état des instances, effectuer une promotion contrôlée de l’instance secondaire.

• Tenter de se connecter au serveur secondaire fraîchement promu.
• Les écritures y sont-elles possibles ?

• Reconstruire l’instance initiale sur p1 comme nouvelle instance secondaire en repartant d’une copie complète de p2 en utilisant pg_basebackup.

• Démarrer cette nouvelle instance.
• Vérifier que les processus adéquats sont bien présents, et que les données précédemment insérées dans les tables créées plus haut sont bien présentes dans l’instance reconstruite.

• Inverser à nouveau les rôles des deux instances afin que p2 redevienne l’instance secondaire, cette fois-ci effectuer la remise en service de l’ancienne instance primaire sans reconstruction.

• Créer l’instance principale en utilisant pg_createcluster sur le serveur p1.

• Vérifier la configuration de la réplication par streaming.
• L’utilisateur dédié sera nommé repli.

• Créer la première instance secondaire sur le serveur p2, par copie à chaud du répertoire de données. Le répertoire dédié aux fichiers de configuration devra également être copié.

• Démarrer la nouvelle instance sur p2 et s’assurer que la réplication fonctionne bien avec ps.
• Tenter de se connecter au serveur secondaire.
• Créer quelques tables pour vérifier que les écritures se propagent du primaire au secondaire.

• En respectant les étapes de vérification de l’état des instances, effectuer une promotion contrôlée de l’instance secondaire.

• Tenter de se connecter au serveur secondaire fraîchement promu.
• Les écritures y sont-elles possibles ?

• Reconstruire l’instance initiale sur p1 comme nouvelle instance secondaire en repartant d’une copie complète de p2 en utilisant pg_basebackup.

• Démarrer cette nouvelle instance.
• Vérifier que les processus adéquats sont bien présents, et que les données précédemment insérées dans les tables créées plus haut sont bien présentes dans l’instance reconstruite.

• Inverser à nouveau les rôles des deux instances afin que p2 redevienne l’instance secondaire, cette fois-ci effectuer la remise en service de l’ancienne instance primaire sans reconstruction.

La mise en place d’une ou plusieurs instances sur le même poste est décrite plus haut.

En préalable, nettoyer les instances précédemment créées sur le serveur.

Réplication asynchrone en flux avec un seul secondaire

• Créer l’instance principale dans /var/lib/pgsql/16/main sur le serveur p1.

# export PGSETUP_INITDB_OPTIONS='--data-checksums'
# /usr/pgsql-16/bin/postgresql-16-setup initdb
Initializing database ... OK
# systemctl start postgresql-16.service

• Mettre en place la configuration de la réplication par streaming.
• L’utilisateur dédié sera nommé repli.

Au sein du fichier /var/lib/pgsql/16/data/pg_hba.conf, ajouter l’entrée ci-dessous pour que l’utilisateur repli (avec l’attribut REPLICATION) ait accès en réplication à l’instance :

# Allow replication
host    replication     repli           10.0.0.22/32            scram-sha-256

Les entrées configurée par défaut qui permettent de faire de la réplication en local peuvent être supprimées :

# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     peer
host    replication     all             127.0.0.1/32            scram-sha-256
host    replication     all             ::1/128                 scram-sha-256

Créer le rôle repli, qui sera dédié à la réplication, en lui affectant le mot de passe confidentiel :

$ createuser --no-superuser --no-createrole --no-createdb --replication -P repli
Enter password for new role:
Enter it again:

Configurer ensuite le fichier .pgpass de l’utilisateur système postgres :

$ echo '*:*:*:repli:confidentiel' >> ~/.pgpass
$ chmod 600 ~/.pgpass

Il faut adapter la configuration pour que PostgreSQL écoute sur l’interface réseau qui sera utilisé pour la réplication (listen_addresses = '*'). Afin d’éviter que la mise en réplication n’échoue car les WAL ont été recyclés par PostgreSQL, il faut dire à PostgreSQL de conserver des WAL (wal_keep_size = '256MB'). Cette modification est facultative mais elle permet d’avoir plus de confort dans les manipulations. Un effet similaire peut être obtenu en utilisant des slots de réplication. La mise à jour de la configuration doit être réalisée dans /var/lib/pgsql/16/data/postgresql.conf.

$ psql -c "\dconfig+ (listen_addresses|wal_keep_size)"

Comme vous pouvez le voir dans la colonne context, listen_addresses nécessite un redémarrage.

# systemctl restart postgresql-16.service  # redémarage
# systemctl status postgresql-16.service   # contrôle

• Créer la première instance secondaire sur le serveur p2, par copie à chaud du répertoire de données avec pg_basebackup.
• Penser à copier les fichiers de configuration

Créer un squelette d’instance sur le serveur p2 :

# /usr/pgsql-16/bin/postgresql-16-setup initdb

Supprimer le répertoire de données :

$ rm -Rf /var/lib/pgsql/16/data

Créer le fichier ~/.pgpass :

$ echo '*:*:*:repli:confidentiel' >> ~/.pgpass
$ chmod 600 ~/.pgpass

Utiliser pg_basebackup pour créer l’instance secondaire :

$ pg_basebackup --pgdata /var/lib/pgsql/16/data \
                --progress \
                --write-recovery-conf \
                --checkpoint fast \
                --host 10.0.0.21 \
                --username repli

23172/23172 kB (100%), 1/1 tablespace

L’option -R ou --write-recovery-conf de pg_basebackup a préparé la configuration de la mise en réplication en créant le fichier standby.signal ainsi qu’en configurant primary_conninfo dans le fichier postgresql.auto.conf (dans les versions antérieures à la 11, il renseignerait recovery.conf) :

$ cat /var/lib/pgsql/16/data/postgresql.auto.conf

primary_conninfo = 'user=repli passfile=''/var/lib/pgsql/.pgpass''
                    channel_binding=prefer host=10.0.0.21 port=5432
                    sslmode=prefer sslcompression=0 sslcertmode=allow sslsni=1
                    ssl_min_protocol_version=TLSv1.2
                    gssencmode=prefer krbsrvname=postgres gssdelegation=0
                    target_session_attrs=any load_balance_hosts=disable'

$ file /var/lib/pgsql/16/data/standby.signal

/var/lib/pgsql/16/data/standby.signal: empty

Les fichiers pg_hba.conf et du postgresql.conf ont été répliqué avec le reste de l’instance présente sur p1. Il faut cependant adapter la configuration du pg_hba.conf pourqu’elle autorise les connexions de réplication depuis p1 :

$ grep -E "host.*replication" /etc/pgsql/16/data/pg_hba.conf

host    replication     repli           10.0.0.21/32            scram-sha-256

• Démarrer l’instance sur p2 et s’assurer que la réplication fonctionne bien avec ps.
• Tenter de se connecter au serveur secondaire.
• Créer quelques tables pour vérifier que les écritures se propagent du primaire au secondaire.

Il ne reste désormais plus qu’à démarrer l’instance secondaire :

# systemctl start  postgresql-16.service   # redémarrage
# systemctl status  postgresql-16.service  # contrôle

La commande ps suivante permet de voir que les deux serveurs sont lancés :

$ ps -o pid,cmd fx

Voici le résultat de la commande sur le seveur p2 :

  PID CMD
12895 /usr/pgsql-16/bin/postgres -D /var/lib/pgsql/16/data/
12896  \_ postgres: logger
12897  \_ postgres: checkpointer
12898  \_ postgres: background writer
12899  \_ postgres: startup recovering 000000010000000000000003
12900  \_ postgres: walreceiver streaming 0/3000148

La même commande exécutée sur le serveur p1 :

  PID CMD
12443 /usr/pgsql-16/bin/postgres -D /var/lib/pgsql/16/data/
12444  \_ postgres: logger
12445  \_ postgres: checkpointer
12446  \_ postgres: background writer
12448  \_ postgres: walwriter
12449  \_ postgres: autovacuum launcher
12450  \_ postgres: logical replication launcher
12940  \_ postgres: walsender repli 10.0.0.22(50520) streaming 0/3000148

Nous avons bien les deux processus de réplication en flux wal sender et wal receiver.

Créons quelques données sur le principal et assurons-nous qu’elles soient transmises au secondaire :

$ createdb b1

$ psql b1

psql (16.1)
Type "help" for help.

b1=# CREATE TABLE t1(id integer);

CREATE TABLE

b1=# INSERT INTO t1 SELECT generate_series(1, 1000000);

INSERT 0 1000000

En exécutant la commande suivante sur les serveurs p1 et p2, on constate que le flux a été transmis :

$ ps -o pid,cmd fx | egrep "(startup|walsender|walreceiver)"

Sur p1 :

12940  \_ postgres: walsender repli 10.0.0.22(50520) streaming 0/71AFD20

Sur p2 :

12899  \_ postgres: startup recovering 000000010000000000000007
12900  \_ postgres: walreceiver streaming 0/71AFD20

Essayons de nous connecter au secondaire et d’exécuter quelques requêtes :

$ psql b1

psql (16.1)
Type "help" for help.

b1=# SELECT COUNT(*) FROM t1;

  count
---------
 1000000

b1=# CREATE TABLE t2(id integer);

ERROR:  cannot execute CREATE TABLE in a read-only transaction

On peut se connecter, lire des données, mais pas écrire.

Le comportement est visible dans le log de l’instance secondaire dans le fichier pointé par /var/lib/pgsql/16/data/current_logfiles :

$ cat /var/lib/pgsql/16/data/current_logfiles

stderr log/postgresql-Thu.log

$ cat /var/lib/pgsql/16/data/current_logfiles
stderr log/postgresql-Thu.log

... LOG:  database system is ready to accept read only connections

PostgreSQL indique bien qu’il accepte des connexions en lecture seule.

Promotion de l’instance secondaire

• En respectant les étapes de vérification de l’état des instances, effectuer une promotion contrôlée de l’instance secondaire.

Sur p1, arrêt de l’instance primaire et vérification de son état :

# systemctl stop postgresql-16.service

$ /usr/pgsql-16/bin/pg_controldata -D /var/lib/pgsql/16/data/ \
| grep -E '(cluster)|(REDO)'

Database cluster state:               shut down
Latest checkpoint's REDO location:    0/71AFE08
Latest checkpoint's REDO WAL file:    000000010000000000000007

Vérification de l’instance secondaire sur p2 :

$ psql -c 'CHECKPOINT;'

$ /usr/pgsql-16/bin/pg_controldata -D /var/lib/pgsql/16/data/ \
| grep -E '(cluster)|(REDO)'

Database cluster state:               in archive recovery
Latest checkpoint's REDO location:    0/71AFE08
Latest checkpoint's REDO WAL file:    000000010000000000000007

L’instance principale est bien arrêtée, l’instance secondaire est bien en archive recovery et les deux sont bien synchronisées.

Promotion de l’instance secondaire :

$ /usr/pgsql-16/bin/pg_ctl -D /var/lib/pgsql/16/data promote

waiting for server to promote.... done
server promoted

• Tenter de se connecter au serveur secondaire fraîchement promu.
• Les écritures y sont-elles possibles ?

Connectons-nous à ce nouveau primaire et tentons d’y insérer des données :

$ psql b1
psql (16.1)
Type "help" for help.

b1=# CREATE TABLE t2(id integer);

CREATE TABLE

b1=# INSERT INTO t2 SELECT generate_series(1, 1000000);

INSERT 0 1000000

Les écritures sont désormais bien possible sur cette instance.

Retour à la normale

• Reconstruire l’instance initiale sur p1 comme nouvelle instance secondaire en repartant d’une copie complète de p2 en utilisant pg_basebackup.

Afin de rétablir la situation, nous pouvons réintégrer l’ancienne instance primaire en tant que nouveau secondaire (sur p1). Pour ce faire, nous devons re-synchroniser les données. Utilisons pg_basebackup comme précédemment après avoir mis de côté les fichiers de l’ancien primaire :

$ mv /var/lib/pgsql/16/data /var/lib/pgsql/16/data.old

$ pg_basebackup --pgdata /var/lib/pgsql/16/data \
                --progress \
                --write-recovery-conf \
                --checkpoint fast \
                --host 10.0.0.22 \
                --username repli

101603/101603 kB (100%), 1/1 tablespace

Créer le fichier standby.signal s’il n’existe pas déjà. Contrôler postgresql.auto.conf (qui contient potentiellement deux lignes primary_conninfo !) et adapter le port :

$ touch /var/lib/pgsql/16/data/standby.signal

$ cat /var/lib/pgsql/16/data/postgresql.auto.conf

primary_conninfo = 'user=repli passfile=''/var/lib/pgsql/.pgpass'' host=10.0.0.22 port=5433 sslmode=prefer sslcompression=0 gssencmode=prefer krbsrvname=postgres target_session_attrs=any'

• Démarrer cette nouvelle instance.

# systemctl start postgresql-16.service   # démarrage
# systemctl status postgresql-16.service  # contrôle

• Vérifier que les processus adéquats sont bien présents, et que les données précédemment insérées dans les tables créées plus haut sont bien présentes dans l’instance reconstruite.

Les processus adéquats sont bien présents :

$ ps -o pid,cmd fx | egrep "(startup|walsender|walreceiver)"

Sur p1 :

13666  \_ postgres: startup recovering 00000002000000000000000C
13667  \_ postgres: walreceiver streaming 0/C000060

Sur p2 :

13676  \_ postgres: walsender repli 10.0.0.21(46610) streaming 0/C000060

$ psql b1

psql (16.1)
Type "help" for help.

En nous connectant à la nouvelle instance secondaire (p2), vérifions que les données précédemment insérées dans la table t2 sont bien présentes :

b1=# SELECT COUNT(*) FROM t2;

  count
---------
 1000000

• Inverser à nouveau les rôles des deux instances afin que p2 redevienne l’instance secondaire, cette fois-ci effectuer la remise en service de l’ancienne instance primaire sans reconstruction.

Afin que l’instance p1 redevienne primaire et celle sur p2 secondaire, on peut ré-appliquer la procédure de promotion vue précédemment dans l’autre sens.

Arrêt de l’instance primaire (p2) et vérification de son état :

# systemctl stop postgresql-16.service

$ /usr/pgsql-16/bin/pg_controldata -D /var/lib/pgsql/16/data/ \
| grep -E '(cluster)|(REDO)'

Database cluster state:               shut down
Latest checkpoint's REDO location:    0/C000148
Latest checkpoint's REDO WAL file:    00000002000000000000000C

Vérification de l’instance secondaire p1 :

$ psql -c 'CHECKPOINT;'
$ /usr/pgsql-16/bin/pg_controldata -D /var/lib/pgsql/16/data/ \
| grep -E '(cluster)|(REDO)'

Database cluster state:               in archive recovery
Latest checkpoint's REDO location:    0/C000148
Latest checkpoint's REDO WAL file:    00000002000000000000000C

L’instance principale est bien arrêtée, l’instance secondaire est bien en archive recovery et les deux sont bien synchronisées.

Promotion de l’instance secondaire :

$ /usr/pgsql-16/bin/pg_ctl -D /var/lib/pgsql/16/data promote

waiting for server to promote.... done
server promoted

La configuration du fichier pg_hba.conf doit être adaptée pour autoriser les connexions depuis 10.0.0.22 et la configuration rechargée.

$ grep "^host.*replication" /var/lib/pgsql/16/data/pg_hba.conf

host    replication     repli           10.0.0.22/32            scram-sha-256

$ /usr/pgsql-16/bin/pg_ctl reload -D /var/lib/pgsql/16/data/

server signaled

Afin que p2 redevienne l’instance secondaire, créer le fichier standby.signal, démarrer le service et vérifier que les processus adéquats sont bien présents :

$ touch /var/lib/pgsql/16/data/standby.signal

# systemctl start postgresql-16.service

$  ps -o pid,cmd fx | egrep "(startup|walsender|walreceiver)"

Sur p1 :

14254  \_ postgres: walsender repli 10.0.0.22(53776) streaming 0/C0002D8

Sur p2 :

13996  \_ postgres: startup recovering 00000003000000000000000C
14172  \_ postgres: walreceiver streaming 0/C0002D8

Au préalable, nettoyer les instances précédemment créées sur le serveur.

# pg_dropcluster --stop 16 main

Réplication asynchrone en flux avec un seul secondaire

• Créer l’instance principale en utilisant pg_createcluster sur le serveur p1.

# pg_createcluster 16 main
Creating new PostgreSQL cluster 16/main ...
...
Ver Cluster Port Status Owner    Data directory              Log file
16  main    5432 down   postgres /var/lib/postgresql/16/main /var/log/postgresql/postgresql-16-main.lo

Le répertoire des données se trouvera sous /var/lib/postgresql/16/main.

Démarrer l’instance, soit avec :

# pg_ctlcluster start 16 main

soit explicitement via systemd :

# systemctl start postgresql@16-main

• Vérifier la configuration de la réplication par streaming.
• L’utilisateur dédié sera nommé repli.

Au sein du fichier /etc/postgresql/16/main/pg_hba.conf, ajouter l’entrée ci-dessous pour que l’utilisateur repli (avec l’attribut REPLICATION) ait accès en réplication à l’instance :

# Allow replication
host    replication     repli           10.0.0.22/32            scram-sha-256

Les entrées configurée par défaut qui permettent de faire de la réplication en local peuvent être supprimées :

# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     peer
host    replication     all             127.0.0.1/32            scram-sha-256
host    replication     all             ::1/128                 scram-sha-256

Créer le rôle repli, qui sera dédié à la réplication, en lui affectant le mot de passe confidentiel :

$ createuser --no-superuser --no-createrole --no-createdb --replication -P repli
Enter password for new role:
Enter it again:

Configurer ensuite le fichier .pgpass de l’utilisateur système postgres :

$ echo '*:*:*:repli:confidentiel' >> ~/.pgpass
$ chmod 600 ~/.pgpass

Il faut adapter la configuration pour que PostgreSQL écoute sur l’interface réseau qui sera utilisé pour la réplication (listen_addresses = '*'). Afin d’éviter que la mise en réplication n’échoue car les WAL ont été recyclés par PostgreSQL, il faut dire à PostgreSQL de conserver des WAL (wal_keep_size = '256MB'). Cette modification est facultative mais elle permet d’avoir plus de confort dans les manipulations. Un effet similaire peut être obtenu en utilisant des slots de réplication. La mise à jour de la configuration doit être réalisée dans /etc/postgresql/16/main.

$ psql -c "\dconfig+ (listen_addresses|wal_keep_size)"

Comme vous pouvez le voir dans la colonne context, listen_addresses nécessite un redémarrage.

# systemctl restart postgresql@16-main  # redémarage
# systemctl status postgresql@16-main   # contrôle

• Créer la première instance secondaire sur le serveur p2, par copie à chaud du répertoire de données avec pg_basebackup.
• Penser à copier les fichiers de configuration

Nous allons réutiliser le squelette de l’instance main pour créer l’instance secondaire.

Arrêter l’instance main :

# systemctl stop postgresql@16-main

$ pg_lsclusters 16 main

Ver Cluster Port Status Owner    Data directory              Log file
16  main    5432 down   postgres /var/lib/postgresql/16/main /var/log/postgresql/postgresql-16-main.log

Supprimer le répertoire de données :

$ rm -Rf /var/lib/postgresql/16/main

Créer le fichier ~/.pgpass :

$ echo '*:*:*:repli:confidentiel' >> ~/.pgpass
$ chmod 600 ~/.pgpass

Utiliser pg_basebackup pour créer l’instance secondaire :

$ pg_basebackup --pgdata /var/lib/postgresql/16/main \
                --progress \
                --write-recovery-conf \
                --checkpoint fast \
                --host 10.0.0.21 \
                --username repli

23110/23110 kB (100%), 1/1 tablespace

L’option -R ou --write-recovery-conf de pg_basebackup a préparé la configuration de la mise en réplication en créant le fichier standby.signal ainsi qu’en configurant primary_conninfo dans le fichier postgresql.auto.conf (dans les versions antérieures à la 11, il renseignerait recovery.conf) :

$ cat /var/lib/postgresql/16/main/postgresql.auto.conf

primary_conninfo = 'user=repli passfile=''/var/lib/postgresql/.pgpass''
                    channel_binding=prefer host=10.0.0.21 port=5432
                    sslmode=prefer sslcompression=0 sslcertmode=allow sslsni=1
                    ssl_min_protocol_version=TLSv1.2
                    gssencmode=prefer krbsrvname=postgres gssdelegation=0
                    target_session_attrs=any load_balance_hosts=disable'

$ file /var/lib/postgresql/16/main/standby.signal

/var/lib/postgresql/16/main/standby.signal: empty

Il faut répercuter les modifications du pg_hba.conf et du postgresql.conf en les adaptant si nécessaire sur la nouvelle instance :

$ grep -E "host.*replication" /etc/postgresql/16/main/pg_hba.conf

host    replication     repli           10.0.0.21/32            scram-sha-256

$ grep -E "^(listen_addresses|wal_keep_size)" /etc/postgresql/16/main/postgresql.conf

listen_addresses = '*'
wal_keep_size = '256MB'

• Démarrer l’instance sur p2 et s’assurer que la réplication fonctionne bien avec ps.
• Tenter de se connecter au serveur secondaire.
• Créer quelques tables pour vérifier que les écritures se propagent du primaire au secondaire.

Il ne reste désormais plus qu’à démarrer l’instance secondaire :

# systemctl start  postgresql@16-main   # redémarrage
# systemctl status  postgresql@16-main  # contrôle

La commande ps suivante permet de voir que les deux serveurs sont lancés :

$ ps -o pid,cmd fx

Voici le résultat de la commande sur le seveur p2 :

 PID CMD
4247 /usr/lib/postgresql/16/bin/postgres -D /var/lib/postgresql/16/main -c config_file=/etc/postgresql/16/main/postgresql.conf
4248  \_ postgres: 16/main: checkpointer
4249  \_ postgres: 16/main: background writer
4250  \_ postgres: 16/main: startup recovering 000000010000000000000003
4251  \_ postgres: 16/main: walreceiver streaming 0/3000148

La même commande exécutée sur le serveur p1 :

 PID CMD
4084 /usr/lib/postgresql/16/bin/postgres -D /var/lib/postgresql/16/main -c config_file=/etc/postgresql/16/main/postgresql.conf
4085  \_ postgres: 16/main: checkpointer
4086  \_ postgres: 16/main: background writer
4088  \_ postgres: 16/main: walwriter
4089  \_ postgres: 16/main: autovacuum launcher
4090  \_ postgres: 16/main: logical replication launcher
4252  \_ postgres: 16/main: walsender repli 10.0.0.22(48570) streaming 0/3000148

Nous avons bien les deux processus de réplication en flux wal sender et wal receiver.

Créons quelques données sur le principal et assurons-nous qu’elles soient transmises au secondaire :

$ createdb b1

$ psql b1

psql (16.1)
Type "help" for help.

b1=# CREATE TABLE t1(id integer);

CREATE TABLE

b1=# INSERT INTO t1 SELECT generate_series(1, 1000000);

INSERT 0 1000000

En exécutant la commande suivante sur les serveurs p1 et p2, on constate que le flux a été transmis :

$ ps -o pid,cmd fx | egrep "(startup|walsender|walreceiver)"

Sur p1 :

4252  \_ postgres: 16/main: walsender repli 10.0.0.22(48570) streaming 0/71A9E50

Sur p2 :

4250  \_ postgres: 16/main: startup recovering 000000010000000000000007
4251  \_ postgres: 16/main: walreceiver streaming 0/71A9E50

Essayons de nous connecter au secondaire et d’exécuter quelques requêtes :

$ psql b1

psql (16.1)
Type "help" for help.

b1=# SELECT COUNT(*) FROM t1;

  count
---------
 1000000

b1=# CREATE TABLE t2(id integer);

ERROR:  cannot execute CREATE TABLE in a read-only transaction

On peut se connecter, lire des données, mais pas écrire.

Le comportement est visible dans le log de l’instance secondaire dans le fichier /var/log/postgresql/postgresql-16-main.log :

... LOG:  database system is ready to accept read only connections

PostgreSQL indique bien qu’il accepte des connexions en lecture seule.

Promotion de l’instance secondaire

• En respectant les étapes de vérification de l’état des instances, effectuer une promotion contrôlée de l’instance secondaire.

Arrêt de l’instance primaire et vérification de son état sur p1 :

# systemctl stop postgresql@16-main

$ /usr/lib/postgresql/16/bin/pg_controldata -D /var/lib/postgresql/16/main \
| grep -E '(cluster)|(REDO)'

Database cluster state:               shut down
Latest checkpoint's REDO location:    0/71A9F38
Latest checkpoint's REDO WAL file:    000000010000000000000007

Vérification de l’instance secondaire sur p2 :

$ psql -c 'CHECKPOINT'

$ /usr/lib/postgresql/16/bin/pg_controldata -D /var/lib/postgresql/16/main \
| grep -E '(cluster)|(REDO)'

Database cluster state:               in archive recovery
Latest checkpoint's REDO location:    0/71A9F38
Latest checkpoint's REDO WAL file:    000000010000000000000007

L’instance principale est bien arrêtée, l’instance secondaire est bien en archive recovery et les deux sont bien synchronisées.

Promotion de l’instance secondaire sur p2 :

$ psql -c 'SELECT pg_promote()'

 pg_promote
------------
 t
(1 row)

• Tenter de se connecter au serveur secondaire fraîchement promu.
• Les écritures y sont-elles possibles ?

Connectons-nous à ce nouveau primaire et tentons d’y insérer des données :

$ psql b1
psql (16.1)
Type "help" for help.

b1=# CREATE TABLE t2(id integer);

CREATE TABLE

b1=# INSERT INTO t2 SELECT generate_series(1, 1000000);

INSERT 0 1000000

Les écritures sont désormais bien possible sur cette instance.

Retour à la normale

• Reconstruire l’instance initiale sur p1 comme nouvelle instance secondaire en repartant d’une copie complète de p2 en utilisant pg_basebackup.

Afin de rétablir la situation, nous pouvons réintégrer l’ancienne instance primaire en tant que nouveau secondaire (sur p1). Pour ce faire, nous devons re-synchroniser les données. Utilisons pg_basebackup comme précédemment après avoir mis de côté les fichiers de l’ancien primaire :

$ mv /var/lib/postgresql/16/main /var/lib/postgresql/16/main.old

$ pg_basebackup --pgdata /var/lib/postgresql/16/main \
                --progress \
                --write-recovery-conf \
                --checkpoint fast \
                --host 10.0.0.22 \
                --username repli

101537/101537 kB (100%), 1/1 tablespace

Vérifier la présence du fichier standby.signal. Contrôler postgresql.auto.conf (qui contient potentiellement deux lignes primary_conninfo !). Le fichiers de configuration de l’instance n’ayant quant à eux pas été modifiés, il n’est pas nécessaire de remodifier la configuration.

$ file /var/lib/postgresql/16/main/standby.signal

$ cat /var/lib/postgresql/16/main/postgresql.auto.conf

primary_conninfo = 'user=repli passfile=''/var/lib/postgresql/.pgpass''
                    channel_binding=prefer host=10.0.0.22 port=5432
                    sslmode=prefer sslcompression=0 sslcertmode=allow sslsni=1
                    ssl_min_protocol_version=TLSv1.2
                    gssencmode=prefer krbsrvname=postgres gssdelegation=0
                    target_session_attrs=any load_balance_hosts=disable'

• Démarrer cette nouvelle instance.

Démarrer le service :

# systemctl start postgresql@16-main     # Démarrage
# systemctl status postgresql@16-main    # Contrôle

• Vérifier que les processus adéquats sont bien présents, et que les données précédemment insérées dans les tables créées plus haut sont bien présentes dans l’instance reconstruite.

Les processus adéquats sont bien présents :

$ ps -o pid,cmd fx | egrep "(startup|walsender|walreceiver)"

Sur p1 (secondaire) :

27488  \_ postgres: 16/main: startup recovering 00000002000000000000000C
27489  \_ postgres: 16/main: walreceiver streaming 0/C000060

Sur p2 (primaire) :

19319  \_ postgres: 16/main: walsender repli 10.0.0.21(45332) streaming 0/C000060

En nous connectant à la nouvelle instance secondaire (p2), vérifions que les données précédemment insérées dans la table t2 sont bien présentes :

$ psql b1

psql (16.1)
Type "help" for help.

b1=# SELECT COUNT(*) FROM t2;

  count
---------
 1000000

• Inverser à nouveau les rôles des deux instances afin que p2 redevienne l’instance secondaire, cette fois-ci effectuer la remise en service de l’ancienne instance primaire sans reconstruction.

Afin que l’instance p1 redevienne primaire et celle sur p2 secondaire, on peut ré-appliquer la procédure de promotion vue précédemment dans l’autre sens.

Arrêt de l’instance primaire (p2) et vérification de son état :

# systemctl stop postgresql@16-main

$ /usr/lib/postgresql/16/bin/pg_controldata -D /var/lib/postgresql/16/main/ \
| grep -E '(cluster)|(REDO)'

Database cluster state:               shut down
Latest checkpoint's REDO location:    0/C000148
Latest checkpoint's REDO WAL file:    00000002000000000000000C

Vérification de l’instance secondaire sur p1 :

$ psql -c 'CHECKPOINT;'
$ /usr/lib/postgresql/16/bin/pg_controldata -D /var/lib/postgresql/16/main/ \
| grep -E '(cluster)|(REDO)'

Database cluster state:               in archive recovery
Latest checkpoint's REDO location:    0/C000148
Latest checkpoint's REDO WAL file:    00000002000000000000000C

L’instance principale est bien arrêtée, l’instance secondaire est bien en archive recovery et les deux sont bien synchronisées.

Promotion de l’instance secondaire :

$ psql -c 'SELECT pg_promote()'

 pg_promote 
------------
 t
(1 row)

Afin que p2 redevienne l’instance secondaire, créer le fichier standby.signal, démarrer le service et vérifier que les processus adéquats sont bien présents :

$ touch /var/lib/postgresql/16/main/standby.signal

#  systemctl start postgresql@16-main

$  ps -o pid,cmd fx | egrep "(startup|walsender|walreceiver)"

Sur p1 :

27562  \_ postgres: 16/main: walsender repli 10.0.0.22(34562) streaming 0/C0002D8

Sur p2 :

19371  \_ postgres: 16/main: startup recovering 00000003000000000000000C
19373  \_ postgres: 16/main: walreceiver streaming 0/C0002D8

Le DCS est un composant critique de tout cluster Patroni. Ne pouvant consacrer un module de formation pour chaque DCS supporté par Patroni, nous avons choisi d’approfondir etcd car il est simple, robuste et populaire.

Ce module aborde la théorie du protocole Raft qui est la source de l’implémentation d’etcd. Cette théorie est utile pour comprendre les réactions d’un cluster etcd ou savoir en interpréter les journaux applicatifs.

Les chapitres suivants se consacrent pleinement à l’étude d’etcd, de son installation à son utilisation et administration.

Raft est un algorithme de consensus répliqué et tolérant aux pannes (Replicated And Fault Tolerant). Ce genre d’algorithme vise à permettre à un ensemble de serveurs de fonctionner comme un groupe cohérent pouvant survivre à la disparition d’un certain nombre de membres.

L’élaboration de Raft part du constat que les algorithmes de consensus comme Paxos sont complexes à comprendre et donc à implémenter. C’est un problème important, car ils sont utilisés dans des applications critiques qui nécessitent d’être bien comprises et maîtrisées. L’un des principaux objectifs lors de l’élaboration de Raft était donc de le rendre, dans la mesure du possible, simple à comprendre et à implémenter en plus d’être : prouvé, complet et fonctionnel.

Avec Raft, les clients dialoguent uniquement avec le nœud leader. Si une requête est envoyée à un nœud secondaire (follower), elle va échouer en renvoyant des informations sur l’adresse du leader. Néanmoins nous verrons plus loin que son implémentation dans etcd lève partiellement cette restriction.

Dans notre infrastructure, les clients d’etcd sont les processus Patroni, et leurs requêtes correspondent à :

• un changement d’état du nœud ;
• une modification de configuration d’une instance.

Raft implémente une machine à états déterministe qui utilise un journal répliqué.

La machine à états joue les modifications les unes après les autres, dans leur ordre d’arrivée. Cela garantit que la machine avance d’un état stable à l’autre et produit le même résultat sur tous les nœuds.

L’algorithme de consensus se charge de maintenir la cohérence du journal répliqué.

Dans Raft chaque nœud est dans l’un des trois états suivant :

• follower (suiveur) : c’est l’état par défaut lorsqu’on démarre un nœud. Dans cet état, le nœud est passif. Il s’attend à recevoir régulièrement un message du leader (heart beat via Append Entries RPC) et potentiellement de nœuds candidats (Request Vote RPC). Il se contente de répondre à ces messages.

• candidate (candidat) : c’est l’état que prend un nœud follower s’il ne reçoit pas de message du leader pendant un certain temps. Dans cet état, il va envoyer des demandes de votes (Request Vote RPC) aux autres nœuds pour se faire élire comme nouveau leader. S’il perd l’élection, il redevient follower.

• leader : c’est l’état que prend un candidat après avoir remporté une élection. Dans cet état, le nœud va envoyer des messages d’ajout dans les journaux (Apprend Entries RPC) à intervalle régulier. Ces messages servent à la fois pour répliquer les commandes envoyées au leader par les clients et pour signifier aux followers que le leader est toujours vivant (heart beat). Si le leader découvre un leader avec un mandat supérieur au sien, il redevient follower (voir règles ci-dessous).

Les mandats (terms) servent à déterminer quand des informations sont obsolètes dans l’agrégat.

Les règles suivantes concernent les mandats :

• chaque mandat commence par une élection ;
• les mandats sont numérotés avec des entiers consécutifs ;
• chaque nœud ne peut voter qu’une fois par mandat ;
• il ne peut y avoir qu’un seul leader par mandat. Il est possible qu’un mandat n’ait pas de leader si une élection a échoué (split vote) ;
• chaque serveur garde une trace du mandat dans lequel il évolue ; l’identifiant de mandat est échangé dans tous les messages.
• si un nœud reçoit un message avec un identifiant de mandat supérieur, il met à jour son identifiant de mandat et redevient follower s’il ne l’est pas déjà ;
• si un nœud reçoit un message avec un identifiant de mandat inférieur au sien, il ignore la demande et renvoie une erreur à son expéditeur.

Raft sépare en trois parties les éléments essentiels pour le consensus :

• élection d’un leader : il ne doit toujours y avoir qu’un seul leader, si un leader disparaît un nouveau doit le remplacer ;
• réplication du journal : le leader reçoit les modifications des clients et les réplique vers les autres serveurs ; le journal du leader fait toujours référence ;
• sécurité & cohérence : si un serveur a appliqué une entrée du journal dans sa machine à état, les autres serveurs doivent appliquer la même entrée provenant de la même position dans le journal.

Le leader informe régulièrement tous les followers de sa présence (heart beart) par l’envoi d’un message d’ajout au journal (Append Entries RPC) qui peut être vide s’il n’y a pas d’activité.

Si le message tarde à arriver sur un nœud, ce dernier présume que le leader a disparu et devient candidat. Il incrémente alors son numéro de mandat, vote pour lui-même et effectue une demande d’élection (Request Vote RPC).

Si le candidat obtient la majorité des votes, il remporte l’élection et devient leader. Il envoie alors un message d’heart beat aux autres serveurs afin de leur signifier la présence d’un nouveau leader.

Si le candidat reçoit un message de heart beat en provenance d’un autre nœud alors qu’il est en train d’attendre des votes, il vérifie le numéro de mandat. Si le mandat de ce serveur est supérieur ou égal au mandat du candidat, cela signifie qu’un autre nœud a été élu leader. Dans ce cas, le candidat devient follower. Sinon, il renvoie un message d’erreur et continue son élection.

Le dernier cas de figure est qu’aucun candidat ne parvienne à remporter l’élection pendant ce mandat. Dans ce cas, les candidats vont atteindre leur timeout d’élection et en démarrer une nouvelle. Ce cas de figure est désigné sous le nom de split vote.

Le temps d’attente avant le timeout est d’une durée aléatoire choisie dans une plage prédéfinie (par exemple 150 ms-300 ms) désignée sous le nom d’election timeout. Cette randomisation limite l’occurrence des demandes de vote simultanées et la multiplication de split votes.

L’application cliente envoie sa commande au leader. Cette commande est ajoutée dans son journal avant d’être envoyée aux followers dans un message d’ajout (Append Entries RPC).

Si une commande est répliquée dans les journaux de la majorité des nœuds de l’agrégat, elle est exécutée par le leader (commitée) qui répond ensuite au client. Le leader conserve une trace de l’index du dernier enregistrement de log appliqué dans la machine à états (commit index), dont la valeur est incluse dans les messages envoyés aux followers (Append Entries RPC). Cette information permet aux followers de savoir quels enregistrements de leur journal peuvent être exécutés par leur machine à états.

Si un follower est indisponible, le leader tente de renvoyer le message jusqu’à ce qu’il soit reçu.

Raft s’appuie sur les numéros d’index (position dans le journal) et de mandat comme prédicats pour garantir la consistance du journal (log matching properties). Si deux entrées de différents journaux ont ces mêmes numéros :

• elles stockent la même commande ;
• les entrées précédentes sont identiques.

Le premier prédicat est garanti par le fait que le leader ne produit qu’une seule entrée avec un numéro d’index donné pendant un mandat. De plus les entrées créées dans le journal ne changent pas de position dans le journal.

Le second prédicat est garanti par la présence supplémentaire des numéros d’index et de mandat de la commande précédente dans chaque demande d’ajout au journal (Append Entries RPC). Le follower n’écrit un enregistrement dans son journal que si l’index et le mandat de l’enregistrement précédent correspondent à ce qu’a envoyé le leader. Sinon la demande du leader est rejetée.

En temps normal, ce contrôle de cohérence ne tombe jamais en échec. Cependant, suite à une élection, plusieurs cas de figure sont possibles :

• le follower est à jour, il n’y a rien à faire ;
• le follower est en retard, il faut lui communiquer les entrées manquantes ;
• le journal du follower contient des entrées qui ne sont pas sur le leader : cela peut arriver lorsqu’un ancien leader redevient follower alors qu’il n’avait pas encore reçu de consensus sur des valeurs qu’il avait écrites dans son journal.

Pour gérer ces trois situations, le leader maintient un index (next index) pour chaque follower qui correspond à la position du prochain enregistrement qui sera envoyé à ce follower. Suite à l’élection, cet index pointe vers la position de l’enregistrement qui suit le dernier enregistrement du journal. De cette manière si le journal d’un follower n’est pas cohérent avec celui du leader, le prochain message d’ajout dans les journaux sera en échec. Le leader va alors décrémenter son compteur d’une position et renvoyer un nouveau message. Ce processus va se répéter jusqu’à ce que le leader et le follower trouvent un point de consistance entre leurs journaux. Une fois cette position trouvée, le follower tronque la suite du journal et applique toutes modifications en provenance du leader.

Quelques protections supplémentaires sont nécessaires pour garantir la cohérence du journal distribué en cas d’incident majeur.

La plus importante est mise en place lors du processus d’élection : les nœuds votants refusent de voter pour un candidat qui est en retard par rapport à eux. Cela est rendu possible grâce à la présence du numéro de mandat et d’index du dernier enregistrement du journal du candidat dans le message de demande de vote (Request Vote RPC). Le numéro de mandat du candidat doit être supérieur ou égal à celui du votant. Si les numéros de mandat sont égaux, les numéros d’index sont comparés avec le même critère.

Pour éviter le statu quo ou l’égalité entre deux nœuds, il faut pouvoir les départager par un déséquilibre du vote et ceci dans un laps de temps donné.

La promotion d’un nœud candidat ne peut avoir lieu que si la majorité des nœuds a voté pour lui.

La tolérance de panne définit combien de nœuds l’agrégat peut perdre tout en restant opérationnel, c’est-à-dire de toujours pouvoir procéder à une élection.

Bien que l’ajout d’un nœud à un cluster de taille impaire semble une bonne idée au premier abord, la tolérance aux pannes est pourtant pire : la tolérance de panne reste inchangée, mais comme il y a plus de nœuds, la probabilité de panne est logiquement plus grande.

Dans Raft, les clients communiquent uniquement avec le leader. Si un autre nœud reçoit un message provenant d’un client, il rejette la demande et communique l’adresse du leader.

En l’état, Raft peut rejouer deux fois les mêmes commandes : par exemple, si un leader plante après avoir validé un enregistrement mais avant d’avoir confirmé son exécution au client. Dans ce cas, le client risque de renvoyer la commande, qui sera exécutée une seconde fois.

Afin d’éviter cela, le client doit associer à chaque commande un numéro unique. La machine à état garde trace du dernier numéro traité, si elle reçoit une commande avec un numéro qui a déjà été traité, elle répond directement sans ré-exécuter la requête.

Immédiatement après l’élection d’un nouveau leader, ce dernier ne sait pas quelles entrées sont exécutées dans son journal. Pour résoudre ce problème immédiatement après son élection, le leader envoie un message vide d’ajout dans le journal (Append Entries RPC) avec un index (next_index) qui pointe sur l’entrée qui suit la dernière entrée de son journal. De cette manière, tous les followers vont se mettre à jour et les entrées du journal du leader pourront être exécutées.

Une dernière précaution est que le leader envoie toujours un heart beat avant de traiter une demande de lecture. De cette manière, on s’assure qu’un autre leader n’a pas été élu entre-temps.

Cette animation permet de simuler le fonctionnement d’un cluster Raft en ajoutant ou enlevant à volonté des nœuds.

Une autre animation plus guidée existe aussi chez The Secret Lives of Data.

Etcd est un serveur de stockage distribué par consensus, écrit en Go avec pour ligne directrice la haute disponibilité. Le projet etcd a été créé à l’origine par CoreOS, puis développé par une communauté de développeurs. Il est distribué sous licence libre (Apache License 2.0). Le nom etcd signifie « etc distribué », etc étant le nom du répertoire dédié au stockage de la configuration sous linux. La configuration consiste généralement en un ensemble de clés/valeurs, c’est le format qu’utilise etcd.

Les données stockées sont répliquées sur tous nœuds composants le cluster, l’algorithme Raft assurant le consensus entre eux à propos des données validées et de leur visibilité.

Etcd implémente l’algorithme Raft. Les principes expliqués précédemment concernant les mécanismes d’élection, la réplication par consensus, le quorum et la tolérance de panne sont donc toujours valables ici.

Contrairement à ce que préconise Raft, il est possible d’adresser des requêtes à un membre follower d’etcd. Toute requête qui nécessite un consensus sera renvoyée automatiquement au leader. Les autres peuvent être traitées par n’importe quel membre (eg: les lectures sérialisées avec par exemple l’option --consistency=s d’etcdctl).

Pour que l’architecture soit résiliente, il faut au minimum qu’elle puisse survivre à la perte d’un de ses membres. Pour qu’une élection soit possible dans ce cas, il faut au minimum 3 serveurs.

Bien qu’aucune limite stricte n’existe, un maximum de 7 nœuds est conseillé. Au delà de 7, l’impact sur les performances en écriture peut devenir trop important.

Un même cluster etcd peut gérer plusieurs agrégats Patroni distincts. En effet, la configuration de Patroni permet de spécifier un chemin différent pour les données de chaque cluster.

De plus, les informations stockées par Patroni sont relativement peu volumineuses. La seule donnée susceptible d’occuper un volume croissant d’espace est l’historique des timelines de PostgreSQL, dont on peut limiter la taille dans le paramétrage de Patroni.

Il est aussi possible d’utiliser le cluster etcd pour d’autres usages. Il faudra alors vérifier que les spécifications du serveur sont suffisantes.

Indisponibilité du Leader

L’indisponibilité du leader donne lieu à une élection afin de le remplacer. Cette élection n’est pas instantanée car déclenchée par le timeout d’un des followers. Pendant l’élection, toute écriture est impossible. Les écritures qui n’ont pas encore été validées peuvent être perdues en fonction d’où elles ont été répliquées et du nouveau leader élu. Les autres actions nécessitant un consensus sont également bloquées.

Si des baux sont encore en cours (leases), le nouveau leader va étendre leur timeout afin d’éviter qu’ils n’expirent à cause de l’indisponibilité induite par la bascule de leader.

Indisponibilité d’un nombre de membres inférieur ou égal à la tolérance de panne

Tant qu’il reste suffisamment de membres dans le cluster pour satisfaire le quorum, il pourra continuer à servir les requêtes des utilisateurs. Si les followers sont habituellement sollicités pour traiter des opérations qui ne nécessitent pas de consensus, cette charge sera déportée vers les serveurs restants, ce qui peut impacter négativement les performances.

Indisponibilité d’un nombre de membres supérieur à la tolérance de panne

Lorsque le cluster perd un nombre de membres supérieur à la tolérance de panne du cluster, il n’est plus possible de réaliser des opérations nécessitant un consensus.

Si les membres impactés reviennent en service, le quorum est de nouveau établi et une nouvelle élection est alors possible. Le cluster peut alors reprendre son fonctionnement normal avec les mêmes limites que lors de la perte du leader.

Si les membres impactés sont définitivement perdus, une intervention est nécessaire. Nous abordons ce sujet plus loin.

Partition réseau

Une partition réseau divise le cluster en deux parties. La partie qui contient suffisamment de serveurs pour maintenir un quorum continue à fonctionner. L’autre partie devient indisponible.

Si le leader est présent dans la partition qui continue à fonctionner, la situation correspond au mode de défaillance où un nombre de membres inférieur ou égal à la tolérance de panne est perdu.

Si le leader est dans la partition qui devient indisponible, la partition conservant le quorum provoque alors une nouvelle élection.

Lorsque les membres de la partition indisponible reviennent en service, ils rejoignent le cluster et rattrapent leur retard.

Échec d’initialisation du cluster (bootstrap)

Le bootstrap est considéré comme un succès lorsque suffisamment de membres se joignent au cluster pour former le quorum nécessaire.

CoreOS utilise des serveurs dual core avec 2 Go de RAM et 80 Go de SSD. Cette configuration peut être prise comme référence pour vos serveurs. Étant donné la quantité faible de données stockée dans etcd par Patroni, l’espace disque peut sans doute être revu à la baisse.

Il est important que le serveur ait suffisamment de mémoire pour contenir une quantité de données équivalente au quota (par défaut 2 Go) avec une marge pour les autres opérations. Si le serveur subit des pressions mémoires et que l’overcommit n’est pas désactivé, il risque d’être pris pour cible par l’OOM Killer.

De notre expérience du support, avoir un stockage et un réseau fiable et performant, en latence comme en débit, est essentiel pour la continuité du service.

Red Hat et autres EL

RedHat a retiré etcd de ses dépôts depuis sa version 8. Il est toujours disponible mais seulement sur les infrastructures OpenStack de RedHat. Voir à ce propos: https://access.redhat.com/solutions/6487641.

Des paquets etcd à jour sont néanmoins fournis depuis le dépôt communautaire PGDG. Attention, le paquet etcd est distribué depuis le dépôt optionnel du PGDG, nommé pgdg-rhel9-extras. Voir à ce propos: https://yum.postgresql.org/news/new-repo-extra-packages/. Dans les commandes suivantes, adapter le numéro de version de l’OS :

sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/\
pgdg-redhat-repo-latest.noarch.rpm
sudo dnf --enablerepo=pgdg-rhel9-extras install -y etcd

Les outils curl et jq sont utiles pour interroger l’API HTTP d’etcd ou travailler avec sa sortie JSON (ou celle de Patroni) :

sudo dnf install jq curl

Si le firewall est activé dans votre distribution EL, il est nécessaire d’en adapter la configuration pour autoriser etcd à communiquer :

sudo firewall-cmd --permanent --new-service=etcd
sudo firewall-cmd --permanent --service=etcd --set-short=Etcd
sudo firewall-cmd --permanent --service=etcd --set-description="Etcd server"
# communication avec les clients
sudo firewall-cmd --permanent --service=etcd --add-port=2379/tcp
# communication avec le cluster
sudo firewall-cmd --permanent --service=etcd --add-port=2380/tcp
sudo firewall-cmd --permanent --add-service=etcd
sudo firewall-cmd --reload

Sur Red Hat, aucun service n’est démarré par défaut. Il est donc nécessaire de l’activer explicitement au démarrage :

sudo systemctl enable etcd.service

Debian/Ubuntu

Les dépôts de Debian et de ses dérivés proposent les paquets client et serveur d’etcd par défaut à partir de la version 12. Par exemple :

sudo apt-get update
/* Debian 12 et après */
sudo apt-get install -y etcd-server etcd-client

Pour Debian 11 et antérieur, un seul paquet etcd regroupait les deux :

sudo apt-get update
/* Debian 11 et avant */
sudo apt-get install -y etcd

Les outils curl et jq sont utiles pour interroger l’API HTTP d’etcd ou travailler avec sa sortie JSON (ou celle de Patroni) :

sudo apt-get install -y jq curl

Sur Debian/Ubuntu, un cluster d’un nœud local est automatiquement créé et le service etcd est démarré immédiatement. Ses données sont stockées dans /var/lib/etcd/default. Cette politique par défaut d’empaquetage Debian ne convenant pas à notre utilisation, il est nécessaire d’arrêter le service et d’en supprimer le répertoire de données avant de créer un nouveau cluster multinœud.

sudo systemctl stop etcd.service
sudo rm -Rf /var/lib/etcd/default

Installation depuis les sources

Il est possible d’installer manuellement etcd sans passer par les paquets proposés ci-dessus.

Sur chacun des nœuds, télécharger les binaires depuis le dépôt Github, puis les copier dans les répertoires adéquats :

ETCD_VER=v3.5.11    # à adapter à la dernière version disponible

curl -L https://github.com/etcd-io/etcd/releases/download/\
${ETCD_VER}/etcd-${ETCD_VER}-linux-amd64.tar.gz \
 -o etcd-${ETCD_VER}-linux-amd64.tar.gz

mkdir etcd-download
tar xzvf etcd-${ETCD_VER}-linux-amd64.tar.gz -C etcd-download --strip-components=1
rm -f etcd-${ETCD_VER}-linux-amd64.tar.gz

sudo cp etcd-download/etcd* /usr/bin/
sudo chmod +x /usr/bin/etcd*

sudo groupadd --system etcd
sudo useradd -s /sbin/nologin --system -g etcd etcd
sudo mkdir -p /var/lib/etcd
sudo chmod 700 /var/lib/etcd
sudo chown -R etcd:etcd /var/lib/etcd/

Etcd supporte trois méthodes de configurations. Chaque paramètre de configuration peut être positionné depuis :

• un argument au binaire etcd ;
• une variable d’environnement ;
• un fichier au format YAML.

Format

Les paramètres passés en argument de la ligne de commande sont préfixés par --.

Les paramètres positionnés en tant que variables d’environnement doivent être préfixés par ETCD_ et déclarées au format screaming snake case : tout en majuscule et en remplaçant les tirets par des underscores.

Le fichier de configuration est à rédiger au format YAML. Un exemple commenté est disponible dans les sources du projet : https://github.com/etcd-io/etcd/blob/main/etcd.conf.yml.sample

Voici quelques exemples de paramètres sous leurs différentes formes:

Précédence

Les paramètres passés en arguments ont la précédence sur ceux positionnés en tant que variables d’environnement.

Si vous fournissez un fichier de configuration (via --config-file ou ETCD_CONFIG_FILE), tout argument ou variable d’environnement est alors ignoré.

Principaux paramètres de configuration

Un nœud etcd écoute sur deux ports distincts : l’un pour les communications avec ses pairs au sein de l’agrégat (par défaut 2380), l’autre pour les échanges avec les clients (par défaut 2379).

Plusieurs thèmes différents sont abordés dans la configuration d’etcd: la configuration locale du nœud, des autres membres, du cluster, de la sécurité, de l’authentification, de la métrologie et des journaux applicatifs, etc.

Voici la liste des principaux paramètres qui nous intéressent :

config-file:

Fichier de configuration à utiliser, au format YAML. Optionnel si les autres paramètres sont passés en tant qu’arguments sur la ligne de commande ou positionnés en tant que variables d’environnement.

name:

Nom du nœud. Doit être unique au sein de l’agrégat.

data-dir:

Chemin vers le répertoire de données.

listen-peer-urls:

URLs locales complètes des ports d’écoute du nœud pour la communication inter-nœuds au sein de l’agrégat. Par exemple : http://1.2.3.4:2380.

listen-client-urls:

URLs locales complètes des ports d’écoute du nœud pour les clients. Par exemple : http://127.0.0.1:2379,http://[::1]:2379,http://1.2.3.4:2379.

advertise-client-urls:

URLs locales complètes des ports d’écoute pour les clients communiquées aux autres nœuds. Par exemple : http://1.2.3.4:2379. Attention, ne positionnez pas ici d’adresse de loopback comme localhost, 127.0.0.1 ou ::1 ! Cela indiquerait à tort à chaque client distant qu’il peut joindre sur une adresse qui lui serait locale le nœud etcd distant. Si le paramètre listen-client-urls contient bien des adresses de loopback, ce n’est que par facilité pour utiliser le CLI etcdctl depuis le nœud etcd sans avoir à connaître son adresse IP externe.

enable-grpc-gateway:

Active la passerelle gRPC vers JSON pour le protocole v3 d’etcd. Patroni utilise l’API JSON d’etcd pour interagir avec lui. Normalement activé par défaut, sauf avant la version 3.5 d’ectd si un fichier de configuration est utilisé.

Les paramètres suivants sont utiles lorsqu’un nœud rejoint un agrégat, pendant ou après la création de ce dernier :

initial-cluster-state:

Indique si le nœud est ajouté dans le cadre de la création d’un agrégat (new) ou dans un agrégat pré-existant (existing).

initial-advertise-peer-urls:

URLs locales complètes des ports d’écoute communiqués aux autres nœuds lors de la création de l’agrégat etcd. Par exemple : http://1.2.3.4:2380.

initial-cluster:

Liste des nœuds attendus lors de la création de l’agrégat etcd. Regroupe toutes les adresses consacrées à la communication entre les nœuds composants l’agrégat. Chaque adresse doit être associée au nom du nœud correspondant par une égalité. Par exemple : etcd1=http://1.2.3.4:2380,etcd2=http://1.2.3.5:2380,etcd3=http://1.2.3.6:2380

initial-cluster-token:

Jeton d’identification utilisé lors de la création de l’agrégat etcd. Ce jeton doit être unique et utilisé une seule fois. Vous pouvez utiliser n’importe quelle chaîne de caractère. Par exemple : token-01

enable-v2:

Activation de l’API v2 si positionné à true (déprécié en v3.5).

La liste complète des paramètres est disponible à l’adresse suivante : https://etcd.io/docs/v3.5/op-guide/configuration/#command-line-flags

Installation par les paquets :

Avec les paquets, les services etcd chargent la configuration d’etcd en tant que variables d’environnements lues depuis un fichier. Par défaut, ce fichier est /etc/etcd/etcd.conf pour le paquet PGDG pour Red Hat et dérivés, et /etc/default/etcd pour Debian/Ubuntu et leurs dérivés. Les paramètres doivent donc y être renseignés avec leur format de variable d’environnement.

Installation manuelle :

Si vous avez installé etcd manuellement, vous devrez créer vous-même votre fichier de service. Voici un exemple :

sudo tee /etc/systemd/system/etcd.service <<_EOF_
[Unit]
Description=Etcd Server
After=network.target

[Service]
User=etcd
Type=notify
WorkingDirectory=/var/lib/etcd/
EnvironmentFile=/etc/etcd/etcd.conf
ExecStart=/usr/bin/etcd
Restart=on-failure
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
_EOF_

sudo systemctl daemon-reload

Créer et compléter le fichier de configuration :

sudo mkdir /etc/etcd
sudo tee /etc/etcd/etcd.conf <<_EOF_
ETCD_NAME="[…]"
ETCD_DATA_DIR="[…]"

ETCD_LISTEN_PEER_URLS="[…]"
ETCD_LISTEN_CLIENT_URLS="[…]"
ETCD_ADVERTISE_CLIENT_URLS="[…]"

ETCD_INITIAL_ADVERTISE_PEER_URLS="[…]"
ETCD_INITIAL_CLUSTER="[…]"
ETCD_INITIAL_CLUSTER_TOKEN="[…]"
ETCD_INITIAL_CLUSTER_STATE="new"
_EOF_

Une fois etcd installé et configuré (en accord avec le service utilisé), il est possible de démarrer le service sur tous les nœuds de l’agrégat.

Que ce soit sous RedHat, Debian ou via l’installation manuelle décrite plus haut, la commande est la suivante :

systemctl start etcd

Les services systemd etcd ici présentés sont tous configurés avec le paramètre Type=notify. Ce paramètre implique que le démon etcd envoie un signal au gestionnaire de service Systemd une fois démarré correctement. Les démons etcd envoient cette notification dès que l’agrégat est capable d’accepter les lectures/écritures des clients, donc lorsque qu’au moins un nœud est déclaré leader, donc après que le quorum du cluster ait été atteint.

Tant qu’aucun leader n’est disponible, le statut du service stagne à activating :

# systemctl status etcd
● etcd.service - etcd - highly-available key value store
     Loaded: loaded (/lib/systemd/system/etcd.service; disabled; preset: enabled)
     Active: activating (start) since Mon 2024-03-11 14:13:18 UTC; 58s ago
[…]

Ci-dessus, le service est démarré depuis 58 secondes, mais aucun leader n’a encore été élu. Une fois suffisamment de nœuds démarrés pour atteindre le quorum et que l’un d’eux remporte l’élection, les démons etcd signalent à Systemd que le service est devenu disponible et son statut passe alors à active :

# systemctl status etcd
● etcd.service - etcd - highly-available key value store
     Loaded: loaded (/lib/systemd/system/etcd.service; disabled; preset: enabled)
     Active: active (running) since Mon 2024-03-11 14:14:26 UTC; 4s ago
[…]

Il est désormais possible d’interroger l’agrégat etcd, par exemple sur sa santé et son statut :

$ etcdctl endpoint --cluster health
http://[…]:2379 is healthy: successfully committed proposal: took = 1.25561ms
http://[…]:2379 is healthy: successfully committed proposal: took = 2.151457ms
http://[…]:2379 is healthy: successfully committed proposal: took = 2.264859ms

$ etcdctl --write-out=table endpoint --cluster status
+-----------------+------------------+---------+---------+-----------+-[…]
|    ENDPOINT     |        ID        | VERSION | DB SIZE | IS LEADER | […]
+-----------------+------------------+---------+---------+-----------+-[…]
| http://[…]:2379 | 2d43bd9a99e8f81c |  3.4.23 |   20 kB |     false | […]
| http://[…]:2379 | 66a8f19c2accae34 |  3.4.23 |   20 kB |      true | […]
| http://[…]:2379 | 738403184a12712e |  3.4.23 |   20 kB |     false | […]
+-----------------+------------------+---------+---------+-----------+-[…]

Pour récupérer ces informations, etcdctl se connecte par défaut sur le port client d’etcd sur l’interface localhost (127.0.0.1:2379). Si vous n’avez pas configuré vos démons pour écouter sur cette interface (paramètre listen-client-urls), vous pouvez préciser où le CLI doit se connecter en utilisant le paramètre --endpoints, par exemple : --endpoints=etcd0.hapat.vm:2379.

Au premier démarrage du cluster, chaque membre crée l’arborescence de travail dans le répertoire pointé par le paramètre etcd data-dir :

~# tree /var/lib/etcd/acme
/var/lib/etcd/acme
└── member
    ├── snap
    │   └── db
    └── wal
        ├── 0.tmp
        └── 0000000000000000-0000000000000000.wal

4 directories, 3 files

etcd est un moteur de stockage clé-valeur hautement disponible et distribué. Il permet d’ajouter/modifier, supprimer et consulter des clés respectivement avec les commandes put, del et get. Il utilise un système MVCC pour préserver les anciennes valeurs d’une clé.

L’exemple ci-dessous montre qu’au fur et à mesure des mises à jour, la révision est changée et que les anciennes révisions sont toujours lisibles :

$ export ETCDCTL_API=3

$ etcdctl put 'database' 'PostgreSQL'

$ etcdctl -w fields get 'database' | grep -E 'Revision|Key|Version|Value'
"Revision" : 246
"Key" : "database"
"CreateRevision" : 246
"ModRevision" : 246
"Version" : 1
"Value" : "PostgreSQL"

/* rev 247 */
$ etcdctl put 'database' 'PostgreSQL 16'

$ etcdctl -w fields get 'database' | grep -E 'Revision|Key|Version|Value'
"Revision" : 247
"Key" : "database"
"CreateRevision" : 246
"ModRevision" : 247
"Version" : 2
"Value" : "PostgreSQL 16"

/* rev 248 */
$ etcdctl put 'other_database' 'None'

/* rev 249 */
$ etcdctl put 'database' 'PostgreSQL 17'

$ function list_revs(){
   key=$1
   min=$2
   max=$3
   for (( rev=$min ; rev<=$max; rev++ )); do
      echo -n "\"rev\" : $rev;"
      etcdctl -w fields --rev $rev get $key | grep -E 'CreateRevision|Key|Version|Value' | tr "\n" ";" | sed -e "s/CreateRevision/CRev/g";
      echo
   done
}

$ list_revs 'database' 246 249
"rev": 246;"Key" : "database";"CRev" : 246;"Version" : 1;"Value" : "PostgreSQL";
"rev": 247;"Key" : "database";"CRev" : 246;"Version" : 2;"Value" : "PostgreSQL 16";
"rev": 248;"Key" : "database";"CRev" : 246;"Version" : 2;"Value" : "PostgreSQL 16";
"rev": 249;"Key" : "database";"CRev" : 246;"Version" : 3;"Value" : "PostgreSQL 17";

Les anciennes versions ne sont pas conservées indéfiniment et peuvent être purgées automatiquement ou manuellement. Ce sujet sera abordé plus en détail dans le paragraphe dédié à la maintenance. On peut voir ci-dessous que la suppression des anciennes révisions d’une clé ne décrémente pas son compteur de version. Les révisions les plus anciennes sont juste inaccessibles.

On voit également que si une clé est supprimée mais que les révisions précédant sa suppression sont toujours accessibles, on peut lire les valeurs de cette clé. La suppression compte comme une révision et donne lieu à l’écriture d’un enregistrement de type tombstone (pierre tombale).

/* rev 250 */
$ etcdctl del 'database'

/* rev 251 */
$ etcdctl put 'database' 'Still Pg'

/* purge les révisions avant 248 */
$ etcdctl compact 248
compacted revision 248

$ list_revs 'database' 246 251
"rev": 246;[…]Error: etcdserver: mvcc: required revision has been compacted
"rev": 247;[…]Error: etcdserver: mvcc: required revision has been compacted
"rev": 248;"Key" : "database";"CRev" : 246;"Version" : 2;"Value" : "PostgreSQL 16";
"rev": 249;"Key" : "database";"CRev" : 246;"Version" : 3;"Value" : "PostgreSQL 17";
"rev": 250;
"rev": 251;"Key" : "database";"CRev" : 251;"Version" : 1;"Value" : "Still Pg";

Pour son stockage physique, etcd utilise une base BoltDB, (une base clé-valeur focalisée sur la simplicité et la fiabilité) via son propre pilote son bbolt. Les révisions sont stockées dans un arbre B+ tree, où chaque révision contient le delta par rapport à la révision précédente. Pour accélérer les accès, un arbre B-tree est stocké en mémoire et pointe vers l’arbre persistant.

Patroni utilise etcd comme stockage pour y conserver les informations sur l’état du cluster.

De même, la configuration dynamique de Patroni est maintenue dans etcd après la création (bootstrap) du cluster. Cette configuration est commune à l’ensemble des membres du cluster Patroni et assure un fonctionnement harmonieux des membres. En plus de la configuration propre à Patroni, elle peut contenir tout ou partie du paramétrage de PostgreSQL.

Contrairement à l’API v2, qui utilisait un espace de stockage avec des répertoires, l’API v3 utilise un espace de stockage « à plat ». Il est cependant toujours possible de spécifier des caractères / dans les noms de clés pour simuler une arborescence.

L’ensemble des paramètres écrits pas Patroni peut être listé avec la commande :

$ etcdctl get --keys-only --prefix /service
/service/acme/config
/service/acme/failover
/service/acme/history
/service/acme/initialize
/service/acme/leader
/service/acme/members/p1
/service/acme/members/p2
/service/acme/members/p3
/service/acme/status

L’API d’etcd supporte deux modes de lectures : linéarisées et sérialisées.

Les lectures linéarisées sont des lectures par quorum, elles garantissent que les données lues ont été commitées et donc présentes sur une majorité de serveurs. Ce type de lecture doit passer par le leader. Cela induit un coup supplémentaire pour les performances puisque cela empêche l’équilibrage de charge sur les followers. Aussi, si la connexion cliente est faite sur un follower, elle doit être redirigée vers le leader.

Les lectures sérialisées peuvent être faites directement sur les followers, c’est l’équivalent des lectures sales (dirty reads) sur une base de données relationnelle. Ce genre de lecture est possible même si le cluster a perdu le quorum.

Il est possible de choisir le type de lecture avec etcdctl comme suit :

etcdctl get --prefix --consistency="l" /
etcdctl get --prefix --consistency="s" /

Si deux serveurs etcd sur trois sont arrêtés manuellement, le cluster est marqué comme unhealthy :

$ etcdctl -w table endpoint --cluster status
[…]
Failed to get the status of endpoint http://[…]:2379 (context deadline exceeded)
[…]
Failed to get the status of endpoint http://[…]:2379 (context deadline exceeded)
+-----------------+[…]-----------+[…]-----------------------+
|    ENDPOINT     |[…] IS LEADER |[…]        ERRORS         |
+-----------------+[…]-----------+[…]-----------------------+
| http://[…]:2379 |[…]     false |[…] etcdserver: no leader |
+-----------------+[…]-----------+[…]-----------------------+

On peut voir que, à la différence des lectures linéarisées, les lectures sérialisées fonctionnent toujours.

$ etcdctl get --prefix --consistency="l" key
[…]
Error: context deadline exceeded

$ get --prefix --consistency="s" key
key
myvalue

Une fonctionnalité très importante pour Patroni est la possibilité d’associer un bail à une clé. La notion de bail dans etcd est nommée lease.

Un lease est défini par un identifiant unique et une durée de validité appelé TTL (Time To Live) et peut être associé à une clé.

Si un lease est associé à une clé, cette dernière est automatiquement détruite par etcd à l’expiration de son TTL. Afin de conserver la clé, l’application cliente doit donc régulièrement émettre des keepalives pour renouveler le TTL avant son expiration.

Cette mécanique est utilisée par Patroni pour identifier de façon fiable et unique le nœud leader au sein du cluster. Lors de l’élection du primaire, chaque nœud Patroni éligible tente de créer en premier la clé leader avec son propre nom et un bail dont l’expiration est fixée par le paramètre ttl de la configuration Patroni.

La requête effectuée par Patroni spécifie explicitement que la clé doit être créée et non mise à jour. Grâce à cette contrainte, si plusieurs nœuds Patroni tentent de créer cette clé leader en même temps, etcd ne peut en valider qu’une seule et unique. La clé est alors créée avec le nom du nœud dont la requête est validée et celui-ci reçoit une confirmation. Tous les autres nœuds reçoivent une erreur.

Du point de vue de Patroni, le nœud désigné par cette clé leader détient le leader lock et peut promouvoir son instance PostgreSQL locale. Le processus Patroni est alors en charge de maintenir le bail de sa clé leader aussi longtemps que possible.

Si le bail de la clé est résilié ou vient à expirer, celle-ci est donc détruite par etcd. La destruction de cette clé est détectée par l’ensemble des nœuds du cluster et une nouvelle élection Patroni et course au leader lock est alors déclenchée.

Ci-après quelques exemples d’utilisation d’un bail avec etcd.

Acquisition d’un bail avec une durée de 300 secondes puis création d’une clé utilisant ce bail :

$ export ETCDCTL_API=3

$ etcdctl lease grant 300
lease 33f88b6b082411c8 granted with TTL(300s)

$ etcdctl put sample value --lease=33f88b6b082411c8
OK

$ etcdctl get sample
sample
value

Révocation d’un bail et vérification de la clé :

$ export ETCDCTL_API=3

$ etcdctl lease revoke 33f88b6b082411c8
lease 33f88b6b082411c8 revoked

$ etcdctl get sample

Cas où une clé disparaît à cause d’un non renouvellement du bail :

$ export ETCDCTL_API=3

$ etcdctl lease grant 30 # acquérir un bail de 30s
lease 33f88b6b082411d1 granted with TTL(30s)

$ etcdctl put sample value --lease=33f88b6b082411d1 # création de la clé
OK

/* renouvellement dans les temps */

$ etcdctl lease keep-alive --once 33f88b6b082411d1
  lease 33f88b6b082411d1 keepalived with TTL(30)

/* lecture tardive sans renouvellement */

$ sleep 30

$ etcdctl get sample

Lors de l’élection d’un primaire, plusieurs nœuds peuvent être candidats en même temps, mais un seul d’entre eux doit être élu pour éviter une situation de split-brain. Pour les départager, le leader est le nœud qui crée la clé. Si la clé existe déjà, toute tentative de création échoue.

L’API v3 d’etcd permet d’implémenter ce comportement via des transactions. Ces transactions se déroulent en trois étapes: compare, success et failure. Si les prédicats de l’étape compare réussissent, les commandes de l’étape success sont exécutées. Dans le cas contraire, les commandes de l’étape failure sont exécutées. Dans tous les cas, les opérations de la transaction sont toutes validées ou annulées de façon atomique.

Ce mécanisme est utilisé par Patroni afin de garantir qu’un seul nœud est capable de créer la clé leader, quel que soit le nombre de concurrents simultanés. Schématiquement, sa transaction est la suivante:

compare: créer la clé "leader"
success: positionner la valeur leader=<nodename>
failure: ERREUR

L’exemple ci-dessous illustre ce comportement. Cinq processus concurrents se disputent la création de la variable leader avec l’outil etcdctl. Les lignes vides sont importantes, elles permettent de délimiter les trois étapes et de laisser une erreur remonter lors de l’étape failure:

$ export ETCDCTL_API=3

$ for i in {1..5}
> do {
>  etcdctl txn &
> } <<_EOS_
> create("leader") = "0"
>
> put leader "$i"
>
>
> _EOS_
> done
FAILURE
SUCCESS

OK
FAILURE
FAILURE
FAILURE

$ etcdctl get leader
leader
4

Nous constatons que sur les cinq tentatives simultanées, une seule réussit, quatre échouent. Les processus s’exécutant en parallèle, les résultats sont affichés dans un ordre indéfini. Dans cet exemple, il semble que ce soit le quatrième processus qui ait créé la clé (indice 4).

En conclusion, lors d’une élection Patroni, tous les candidats acceptés se font concurrence pour créer cette clé en premier. Grâce à etcd, nous avons la garantie qu’un seul l’obtient réellement.

Le protocole v3 utilise gRPC pour son transport. Ce protocole permet à etcd de faire de l’authentification à chaque connexion, et non à chaque requête comme le faisait le protocole v2.

Les méta-données utilisées pour la gestion des droits sont aussi stockées dans etcd, l’algorithme de consensus Raft est donc utilisé pour les gérer.

etcd permet de créer des utilisateurs et des rôles. On peut donner des droits à un rôle que l’on assigne aux utilisateurs. Les opérations de gestions des utilisateurs et rôles peuvent être effectuées avec les sous-commandes des sections user et role de etcdctl.

$ export ETCDCTL_API=3

$ etcdctl user add root
Password of root: 
Type password of root again for confirmation: 
User root created

$ etcdctl user add patroni
Password of patroni: 
Type password of patroni again for confirmation: 
User patroni created

$ etcdctl user add admin
Password of admin:
Type password of admin again for confirmation:
User admin created

$ etcdctl role add root
Role root created

$ etcdctl role add patroni
Role patroni created

$ etcdctl user grant-role patroni patroni
Role patroni is granted to user patroni

$ etcdctl user grant-role admin root
Role root is granted to user admin

Le rôle root peut être attribué à n’importe quel utilisateur. Il a les permissions pour :

• accéder à l’ensemble de données en lecture et écriture ;
• changer la configuration d’authentification ;
• réaliser des tâches de maintenance.

La liste des utilisateurs et rôles peut être consultée avec la sous-commande list et le détail de leur configuration peut être consulté avec la sous-commande get.

L’authentification doit être activée avec etcdctl pour être effective. Sans action supplémentaire, l’accès à etcd est ouvert à tous. Contrairement à l’API V2, aucun utilisateur guest n’est créé lors de l’activation, il n’y a donc pas d’action supplémentaire à prévoir de ce côté.

$ etcdctl auth enable
[…]
Authentication Enabled

Il faut désormais s’authentifier pour utiliser la plupart des fonctions d’etcd.

$ etcdctl get --prefix /
[…]
Error: etcdserver: user name is empty

Il faut également avoir les droits pour accéder aux clés.

$ etcdctl --user root:root put key value
OK

$ etcdctl --user patroni:patroni get
[…]
Error: etcdserver: permission denied

$ etcdctl --user root:root get key
key
value

$ etcdctl --user admin:admin get key
key
value

etcd est un stockage clé-valeur ce qui permet de définir des droits sur une plage de données, contrairement à un système de fichiers par exemple. Cela signifie que l’on peut définir des droits sur des clés qui n’existent pas encore.

$ etcdctl --user root:root role grant-permission --prefix patroni readwrite /service/

$ etcdctl --user root:root role get patroni
Role patroni updated
Role patroni
KV Read:
    [/service/, /service0) (prefix /service/)
KV Write:
    [/service/, /service0) (prefix /service/)

On peut désormais écrire et lire les clés de l’intervalle [/service/, /service0) :

$ etcdctl --user patroni:patroni put /service/mydata 'is secure'
OK

$ etcdctl --user patroni:patroni get --prefix /service/
/service/mydata
is secure

Suivant le besoin, les permissions peuvent être révoquées en retirant la permission au rôle :

$ etcdctl --user root:root role revoke-permission --prefix patroni /service/
Permission of range [/service/, /service0) is revoked from role patroni

$ etcdctl --user patroni:patroni get --prefix /service/
[…]
Error: etcdserver: permission denied

ou en retirant le rôle à l’utilisateur :

$ etcdctl --user root:root user revoke-role admin root
Role root is revoked from user admin

$ etcdctl --user admin:admin get --prefix /service/
[…]
Error: etcdserver: permission denied

Les rôles et utilisateurs peuvent également être supprimés :

$ etcdctl --user root:root user del patroni

$ etcdctl --user root:root role del patroni

Communications avec les clients

Plusieurs options permettent de configurer le chiffrement des communications avec les clients :

--cert-file:

Certificat utilisé pour le chiffrement des connexions clientes. Si cette option est activée advertise-client-urls peut utiliser HTTPS.

--key-file:

Clé pour le certificat.

--client-cert-auth:

Quand ce paramètre est activé, etcd va vérifier toutes les requêtes HTTPS reçues pour s’assurer que le certificat client est signé par l’autorité de certification. Si l’authentification est activée, le certificat peut être utilisé uniquement si le nom d’utilisateur spécifié correspond à celui spécifié dans les champs common name du certificat.

--trusted-ca-file:

Certificat de l’autorité de certification.

Communications au sein du cluster

Plusieurs options permettent de configurer le chiffrement des communications entre les membres du cluster etcd :

--peer-cert-file:

Certificat utilisé pour le chiffrement des connexions entre les membres du cluster.

--peer-key-file:

Clé pour le certificat.

--peer-client-cert-auth:

Quand ce paramètre est activé, etcd va vérifier toutes les requêtes entre les membres du cluster pour s’assurer que les certificats sont signés par l’autorité de certification.

--peer-trusted-ca-file:

Certificat de l’autorité de certification.

Autres paramètres

Plusieurs autres paramètres sont valides de manière transverse :

--cipher-suites:

liste de suite de cipher TLS supportés.

--tls-min-version:

version minimale de TLS supportée par etcd.

--tls-max-version:

version maximale de TLS supportée par etcd.

Cas de Patroni

À cause d’un problème dans la librairie gRPC de python, l’authentification par certificat client comportant un common name pour l’association avec un utilisateur etcd ne fonctionne pas avec gRPC/Patroni.

Lorsque le quorum est irrémédiablement perdu, il est nécessaire de recréer le cluster etcd.

Sauvegarde

Il est possible de sauvegarder un serveur à chaud grâce à l’outil etcdctl. La sauvegarde doit être exécutée sur un membre spécifique. Voici un exemple depuis un serveur sur lequel l’authentification est activée :

$ unset ETCDCTL_ENDPOINTS  #  pour éviter un conflit avec --endpoints
$ etcdctl --endpoints http://10.0.0.11:2379 \
        --user root:root \
        snapshot save /tmp/mysnap.etcd.save
{}
{"level":"info","ts":"2023-10-26T16:10:06.347+0200","caller":"clientv3/maintenance.go:200","msg":"opened snapshot stream; downloading"}
{"level":"info","ts":1698329406.3474212,"caller":"snapshot/v3_snapshot.go:127","msg":"fetching snapshot","endpoint":"http://10.0.0.11:2379"}
{"level":"info","ts":"2023-10-26T16:10:06.349+0200","caller":"clientv3/maintenance.go:208","msg":"completed snapshot read; closing"}
{"level":"info","ts":1698329406.3582983,"caller":"snapshot/v3_snapshot.go:142","msg":"fetched snapshot","endpoint":"http://10.0.0.11:2379","size":"53 kB","took":0.11860325}
{"level":"info","ts":1698329406.358513,"caller":"snapshot/v3_snapshot.go:152","msg":"saved","path":"/root/mysnap.etcd.save"}
Snapshot saved at /tmp/mysnap.etcd.save

Si le serveur est arrêté, il est possible de copier le fichier $ETCD_DATA_DIRECTORY/member/snap/db.

Il est possible de consulter des métadonnées sur les snapshots avec la commande suivante :

$ etcdctl --write-out=table snapshot status /tmp/mysnap.etcd.save
+----------+----------+------------+------------+
|   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| 3e3d7361 |       11 |         20 |      25 kB |
+----------+----------+------------+------------+

Restauration

Le fichier sauvegardé peut être restauré avec la commande etcdctl. L’ensemble des membres du cluster doivent être restaurés en utilisant la même sauvegarde. L’opération crée un nouveau répertoire de données et écrase certaines métadonnées, comme les identifiants des membres et du cluster. Les membres assument donc une nouvelle identité ce qui les empêche de joindre l’ancien cluster.

Par défaut, etcdctl va vérifier l’intégrité de la sauvegarde lors de la restauration. Cela n’est possible qu’avec une sauvegarde réalisée avec etcdctl, ce dernier ajoutant à la sauvegarde ces données d’intégrité. Pour restaurer à partir de la copie du fichier de base de données, il est nécessaire d’ajouter l’option --skip-hash-check.

La restauration crée un nouveau répertoire de données pour chaque membre.

/* sur le membre e1 */
$ sudo chown etcd:etcd /var/lib/etcd

$ sudo -u etcd etcdctl snapshot restore /tmp/mysnap.etcd.save \
  --name etcd1 \
  --data-dir /var/lib/etcd/new \
  --initial-cluster etcd1=http://10.0.0.11:2380,\
etcd2=http://10.0.0.12:2380,etcd3=http://10.0.0.13:2380 \
  --initial-cluster-token etcd-cluster-1 \
  --initial-advertise-peer-urls http://10.0.0.11:2380
{"level":"info","ts":1701874064.4195023,"caller":"snapshot/v3_snapshot.go:296","msg":"restoring snapshot","path":"/tmp/mysnap.etcd.save","wal-dir":"/var/lib/etcd/new/member/wal","data-dir":"
/var/lib/etcd/new","snap-dir":"/var/lib/etcd/new/member/snap"}
{"level":"info","ts":1701874064.4401946,"caller":"mvcc/kvstore.go:388","msg":"restored last compact revision","meta-bucket-name":"meta","meta-bucket-name-key":"finishedCompactRev","restored-
compact-revision":4}
{"level":"info","ts":1701874064.4586802,"caller":"membership/cluster.go:392","msg":"added member","cluster-id":"3c425733f8f92ab","local-member-id":"0","added-peer-id":"392a31edc7fd2f21","add
ed-peer-peer-urls":["http://10.0.0.11:2380"]}
{"level":"info","ts":1701874064.4682066,"caller":"membership/cluster.go:392","msg":"added member","cluster-id":"3c425733f8f92ab","local-member-id":"0","added-peer-id":"8db8de0f2f58d643","added-peer-peer-urls":["http://10.0.0.12:2380"]}
{"level":"info","ts":1701874064.4689171,"caller":"membership/cluster.go:392","msg":"added member","cluster-id":"3c425733f8f92ab","local-member-id":"0","added-peer-id":"fdcf639378827052","add
ed-peer-peer-urls":["http://10.0.0.13:2380"]}
{"level":"info","ts":1701874064.5160108,"caller":"snapshot/v3_snapshot.go:309","msg":"restored snapshot","path":"/tmp/mysnap.etcd.save","wal-dir":"/var/lib/etcd/new/member/wal","data-dir":"/
var/lib/etcd/new","snap-dir":"/var/lib/etcd/new/member/snap"}

Exécuter ensuite la même commande sur les autres membres en adaptant les adresses. Sur etcd2 :

$ sudo chown etcd:etcd /var/lib/etcd

$ sudo -u etcd etcdctl snapshot restore /tmp/mysnap.etcd.save \
  --name etcd2 \
  --data-dir /var/lib/etcd/new \
  --initial-cluster e1=http://10.0.0.11:2380,\
etcd2=http://10.0.0.12:2380,etcd3=http://10.0.0.13:2380 \
  --initial-cluster-token etcd-cluster-1 \
  --initial-advertise-peer-urls http://10.0.0.12:2380

Sur etcd3 :

$ sudo chown etcd:etcd /var/lib/etcd

$ sudo -u etcd etcdctl snapshot restore /tmp/mysnap.etcd.save \
  --name etcd3 \
  --data-dir /var/lib/etcd/new \
  --initial-cluster etcdc1=http://10.0.0.11:2380,\
etcd2=http://10.0.0.12:2380,etcd3=http://10.0.0.13:2380 \
  --initial-cluster-token etcd-cluster-1 \
  --initial-advertise-peer-urls http://10.0.0.13:2380

Vérifier que le fichier de configuration utilisé par le service contient les bonnes informations, puis démarrer le service sur chaque serveur :

# systemctl start etcd

Vérifier la santé du cluster :

$ etcdctl -w table --user root:root endpoint --cluster health
+-----------------+--------+-------------+-------+
|    ENDPOINT     | HEALTH |    TOOK     | ERROR |
+-----------------+--------+-------------+-------+
|  10.0.0.13:2379 |   true | 89.852914ms |       |
|  10.0.0.12:2379 |   true | 64.684492ms |       |
|  10.0.0.11:2379 |   true |  87.22009ms |       |
+-----------------+--------+-------------+-------+

$ etcdctl -w table --user root:root endpoint --cluster status
+-----------------+------------------+---------+---------+-----------+-[…]
|    ENDPOINT     |        ID        | VERSION | DB SIZE | IS LEADER | […]
+-----------------+------------------+---------+---------+-----------+-[…]
|  10.0.0.11:2379 | 392a31edc7fd2f21 |  3.4.23 |   25 kB |     false | […]
|  10.0.0.12:2379 | 8db8de0f2f58d643 |  3.4.23 |   25 kB |     false | […]
|  10.0.0.13:2379 | fdcf639378827052 |  3.4.23 |   25 kB |      true | […]
+-----------------+------------------+---------+---------+-----------+-[…]

Cas particulier de Patroni

Patroni effectue une sauvegarde régulière de sa configuration en cas de problème rendant le cluster etcd complètement inopérant. Il est donc possible de recréer un nouveau cluster etcd à la même adresse, Patroni y recrée sa configuration dès qu’il peut s’y reconnecter. En fonction de la configuration choisie, il sera peut être nécessaire de recréer la configuration de l’authentification au préalable.

Pour retirer un membre, ici etcd1, il faut récupérer son identifiant :

$ export ETCDCTL_API=3

$ etcdctl --user root:root -w table member list
+------------------+---------+-------+-[…]
|        ID        | STATUS  | NAME  | […]
+------------------+---------+-------+-[…]
| 8766ab400c82bb8b | started | etcd1 | […]
| 8db8de0f2f58d643 | started | etcd2 | […]
| fdcf639378827052 | started | etcd3 | […]
+------------------+---------+-------+-[…]

On peut ensuite retirer le membre du cluster en utilisant son identifiant :

$ etcdctl --user root:root member remove 8766ab400c82bb8b
Member 8766ab400c82bb8b removed from cluster 4c539c130865dd95

Le nouveau membre peut ensuite être déclaré :

$ etcdctl --user root:root member add etcd1 --peer-urls=http://10.0.0.11:2380
Member fba06dcbe3cdd363 added to cluster 4c539c130865dd95

ETCD_NAME="etcd1"
ETCD_INITIAL_CLUSTER="etcd2=http://10.0.0.12:2380,etcd3=http://10.0.0.13:2380,etcd1=http://10.0.0.11:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.0.11:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"

Le nœud peut ensuite être réintroduit dans le cluster. Dans ce cas, il s’agit du même serveur, il faut donc supprimer le répertoire de données et mettre à jour la configuration pour spécifier que le cluster existe déjà.

# rm -Rf /var/lib/etcd/acme

# grep ETCD_INITIAL_CLUSTER_STATE /etc/default/etcd
ETCD_INITIAL_CLUSTER_STATE="existing"

Démarrer le service sur le nouveau membre :

systemctl start etcd

Vérifier la santé du cluster :

$ etcdctl -w table --user root:root endpoint --cluster health
+-----------------+--------+------------+-------+
|    ENDPOINT     | HEALTH |    TOOK    | ERROR |
+-----------------+--------+------------+-------+
|  10.0.0.13:2379 |   true | 9.238291ms |       |
|  10.0.0.12:2379 |   true | 6.268266ms |       |
|  10.0.0.11:2379 |   true | 8.744718ms |       |
+-----------------+--------+------------+-------+

$ etcdctl -w table --user root:root endpoint --cluster status
+-----------------+------------------+---------+---------+-----------+[…]
|    ENDPOINT     |        ID        | VERSION | DB SIZE | IS LEADER |[…]
+-----------------+------------------+---------+---------+-----------+[…]
|  10.0.0.11:2379 | fba06dcbe3cdd363 |  3.4.23 |   25 kB |     false |[…]
|  10.0.0.12:2379 | 169e6880896105ec |  3.4.23 |   25 kB |     false |[…]
|  10.0.0.13:2379 | 9153db243246fd2b |  3.4.23 |   25 kB |      true |[…]
+-----------------+------------------+---------+---------+-----------+[…]

Rétention du journal Raft

etcd conserve un certain nombre d’entrées Raft en mémoire avant de compacter l’historique Raft. Ce nombre est défini avec --snapshot-count. Une fois le seuil atteint, les données sont écrites sur disque et les entrées tronquées de l’historique. Quand un follower demande des informations concernant un index déjà compacté, le leader est alors forcé de lui renvoyer un snapshot complet des données.

Une valeur importante de --snapshot-count peut causer des pressions mémoires sur le serveur et impacter les performances. Il est donc conseillé de ne pas dépasser 100 000. Une valeur trop basse cause un compactage fréquent des données ce qui sollicite beaucoup de garbage collector de Go. Suivant les versions, ce paramètre est confirmé à 10 000 ou 100 000. Pour un serveur etcd dédié à Patroni, changer ce paramètre est inutile.

Compaction manuelle du journal de Raft et maintenance automatique

etcdctl permet de compacter l’historique Raft manuellement avec la commande etcdctl compact <revision>.

Voici un exemple :

$ export ETCDCTL_API=3

$ etcdctl -w fields --user root:root put somekey somevalue
"ClusterID" : 271383054466912939
"MemberID" : 4119159706516008737
"Revision" : 12
"RaftTerm" : 2

$ etcdctl -w fields --user root:root put somekey somenewvalue
"ClusterID" : 271383054466912939
"MemberID" : 4119159706516008737
"Revision" : 13
"RaftTerm" : 2

$ etcdctl -w fields --user root:root get --rev 12 somekey
"ClusterID" : 271383054466912939
"MemberID" : 4119159706516008737
"Revision" : 13
"RaftTerm" : 2
"Key" : "somekey"
"CreateRevision" : 12
"ModRevision" : 12
"Version" : 1
"Value" : "somevalue"
"Lease" : 0
"More" : false
"Count" : 1

$ etcdctl --user root:root compact 13
compacted revision 13

$ etcdctl -w fields --user root:root get --rev 12 somekey
[…]
Error: etcdserver: mvcc: required revision has been compacted

etcd dispose d’un système de compactage automatique de l’historique Raft qui connait des améliorations et évolutions à chaque version.

Il est possible de définir une période de rétention en heures avec le paramètre --auto-compaction-retention. Le compacteur est lancé automatiquement toutes les heures depuis la version 3.2.0. En cas d’erreur, il se relance après cinq minutes. Pour un serveur etcd dédié à Patroni, cet automatisme est suffisant.

Défragmentation

La compaction de l’historique Raft provoque une fragmentation de la base de donnée etcd. Cette fragmentation crée de l’espace à l’intérieur de la base, utilisable par etcd mais pas rendu au système.

Il est possible de récupérer cet espace avec etcdctl :

$ export ETCDCTL_API=3
$ etcdctl --user root:root defrag --cluster
Finished defragmenting etcd member[http://10.0.0.11:2379]
Finished defragmenting etcd member[http://10.0.0.12:2379]
Finished defragmenting etcd member[http://10.0.0.13:2379]

Étant donné la faible quantité de données et de modifications dans un cluster etcd dédié à Patroni, cette opération n’a pas besoin d’être fréquente. Il faut surveiller que l’espace de stockage reste inférieur au quota défini (voir plus loin).

Space quota

Sans quota, etcd pourrait avoir des performances médiocres si l’espace de donnée est trop important. Il pourrait également remplir l’espace disque disponible, ce qui entrainerait un comportement non prévu de etcd. BoltDB stocke l’intégralité de ses données en mémoire afin d’améliorer les performances, c’est un point à considérer si on augmente le quota.

Lorsque l’espace de stockage d’etcd dépasse le quota défini, une alerte est déclenchée sur tout le cluster qui passe en mode maintenance. Seules les lectures et les suppressions de clés sont alors autorisées. Il faut faire de la place dans la base ou la défragmenter et acquitter l’erreur de quota pour que le cluster reprenne un comportement normal.

Pour l’exemple, nous allons diminuer la taille du quota de 2 Go à 512 Mo.

$ echo "ETCD_QUOTA_BACKEND_BYTES=$((512*1024*1024))" \
  | sudo tee -a /etc/default/etcd

$ systemctl restart etcd

On remplit ensuite l’espace de stockage des clés en mettant à jour en permanence la clé key :

$ while [ 1 ]; do
> dd if=/dev/urandom bs=1024 count=1024 \
>   | ETCDCTL_API=3 etcdctl --user root:root put key || break;
> done
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0859895 s, 12.2 MB/s
[…]
OK
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0344256 s, 30.5 MB/s
{"level":"warn","ts":"2023-12-07T10:10:02.012Z","caller":"clientv3/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"endpoint://client-78488c2e-dec2-422c-9099-a9e9fd8eb1d2/10.0.0.11:2379","attempt":0,"error":"rpc error: code = ResourceExhausted desc = etcdserver: mvcc: database space exceeded"}
Error: etcdserver: mvcc: database space exceeded

Dans les traces on voit :

Dec 07 10:01:02 etcd2 etcd[1740]: alarm NOSPACE raised by peer 8db8de0f2f58d643

Si on consulte la santé du cluster, on voit que le cluster est toujours marqué healthy, mais le statut montre une alarme.

$ etcdctl -w table --user root:root endpoint status --cluster
+------------------[…]+---------+[…]-------------------------------+
|        ENDPOINT  […]| DB SIZE |[…]           ERRORS              |
+------------------[…]+---------+[…]-------------------------------+
|  http://10.0.0.11[…]|  537 MB |[…] memberID:10212156311862826563 |
|                  […]|         |[…]               alarm:NOSPACE   |
|  http://10.0.0.12[…]|  537 MB |[…] memberID:10212156311862826563 |
|                  […]|         |[…]               alarm:NOSPACE   |
|  http://10.0.0.13[…]|  537 MB |[…] memberID:10212156311862826563 |
|                  […]|         |[…]               alarm:NOSPACE   |
+------------------[…]+---------+[…]-------------------------------+

$ etcdctl -w table --user root:root endpoint health --cluster
+------------------------+--------+-------------+-------+
|        ENDPOINT        | HEALTH |    TOOK     | ERROR |
+------------------------+--------+-------------+-------+
|  http://10.0.0.11:2379 |   true | 24.293137ms |       |
|  http://10.0.0.13:2379 |   true | 23.117282ms |       |
|  http://10.0.0.12:2379 |   true | 11.770651ms |       |
+------------------------+--------+-------------+-------+

En consultant la clé, il est possible de trouver le nombre de versions créées :

$ etcdctl --user root:root -w json get --prefix key | jq "
>.kvs[] | {
>   key: .key |
>   @base64d,
>   create_revision: .create_revision,
>   mod_revision: .mod_revision,
>   version: .version
> }"
{
  "key": "key",
  "create_revision": 520,
  "mod_revision": 1020,
  "version": 508
}

Pour compacter, il faut récupérer le numéro de révision le plus récent afin de l’utiliser comme référence.

$ export ETCDCTL_API=3

$ rev=$(etcdctl endpoint status --write-out="json" \
  | jq ".[].Status.header.revision")

$ etcdctl --user root:root compact $rev
compacted revision 1516

Il est ensuite possible de défragmenter :

$ etcdctl --user root:root defrag --cluster
Finished defragmenting etcd member[http://10.0.0.11:2379]
Finished defragmenting etcd member[http://10.0.0.12:2379]
Finished defragmenting etcd member[http://10.0.0.13:2379]

Et ne pas oublier de lever l’alarme :

$ etcdctl alarm disarm
memberID:10212156311862826563 alarm:NOSPACE

Note : L’identifiant est fourni sous forme numérique, c’est aussi le cas si vous affichez les informations au format JSON. La plupart des commandes n’acceptent que des memberid en hexadécimal. Si on convertit en hexadécimal l’identifiant ci-dessus, on obtient bien 8db8de0f2f58d643.

La vérification de l’état des nœuds montre ensuite que l’alerte est levée et l’espace récupéré.

$ etcdctl -w table --user root:root endpoint status --cluster
+------------------[…]+---------[…]+--------+
|        ENDPOINT  […]| DB SIZE […]| ERRORS |
+------------------[…]+---------[…]+--------+
|  http://10.0.0.11[…]|  1.1 MB […]|        |
|  http://10.0.0.12[…]|  1.1 MB […]|        |
|  http://10.0.0.13[…]|  1.1 MB […]|        |
+------------------[…]+---------[…]+--------+

endpoint /debug

Si les traces sont configurées en mode débogage (--log-level=debug), le serveur etcd exporte les informations de débogage sur le endpoint /debug. Cela impacte les performances et augmente la quantité de traces produites.

Le endpoint /debug/pprof peut être utilisé pour profiler le CPU, la mémoire, les mutex et les routines Go.

endpoint /metrics

Le endpoint /metrics permet d’exporter des statistiques vers Prometheus. Des alertes par défaut sont disponibles sur github.

Graphana supporte Prometheus, on peut donc utiliser les métriques produites par le endpoint pour alimenter de la métrologie. Il existe déjà un dashboard etcd prévu à cet effet.

Ce endpoint permet d’exposer de nombreuses statistiques.

Les statistiques concernant le serveur sont préfixées par etcd_server_. On trouve notamment :

• has_leader : vaut 1 si le serveur a un leader ; si un serveur n’a pas de leader, il est indisponible. Si aucun serveur du cluster n’a de leader, le cluster est indisponible.
• leader_changes_seen_total : comptabilise le nombre de changements de leader vu par le serveur. Si ce nombre est élevé cela signifie que le leader est instable.
• proposals_committed_total : comptabilise le nombre de propositions de consensus commitées sur le serveur. Il est possible d’avoir des valeurs différentes sur les serveurs ; une différence importante indique que le nœud est à la traîne.
• proposals_applied_total : comptabilise le nombre de propositions de consensus appliqués par le serveur. Les propositions commitées sont appliquées de manière asynchrone. Une différence importante entre demandes commitées et appliquées indique que le serveur est lent ou surchargé.
• proposals_pending : comptabilise le nombre de propositions en attente de commit.
• proposals_failed_total : comptabilise le nombre de propositions qui ont échoué. Cela peut être dû a deux choses : une élection qui échoue ou un perte de quorum du cluster.

Voici un exemple :

$ curl -s -X GET http://10.0.0.11:2379/metrics | grep \
    -e "^etcd_server_has_leader" \
    -e "^etcd_server_leader_changes_seen_total" \
    -e "^etcd_server_proposals_.*\s"
etcd_server_has_leader 1
etcd_server_leader_changes_seen_total 1
etcd_server_proposals_applied_total 2330
etcd_server_proposals_committed_total 2330
etcd_server_proposals_failed_total 4
etcd_server_proposals_pending 0

Concernant le stockage, les statistiques sont préfixées par etcd_server_, par exemple :

• wal_fsync_duration_seconds : la latence des fsync réalisés par etcd pour persister les entrées de log sur disque (dans les WAL) avant de les appliquer ;
• backend_commit_duration_seconds : la latence des fsync appelés par des backends pour commiter sur disque un snapshot incrémental de ses plus récents changements.

Des latences importantes au niveau de ces deux métriques indiquent souvent des problèmes au niveau du disque et peuvent provoquer des élections à cause de timeouts.

$ curl -s -X GET http://10.0.0.11:2379/metrics \
  | grep -e "^etcd_disk_wal_fsync_duration_seconds" \
         -e "^etcd_disk_backend_commit_duration_seconds"
etcd_disk_backend_commit_duration_seconds_bucket{le="0.001"} 0
[…]
etcd_disk_backend_commit_duration_seconds_bucket{le="+Inf"} 13
etcd_disk_backend_commit_duration_seconds_sum 0.273494819
etcd_disk_backend_commit_duration_seconds_count 13
etcd_disk_wal_fsync_duration_seconds_bucket{le="0.001"} 0
[…]
etcd_disk_wal_fsync_duration_seconds_bucket{le="+Inf"} 55
etcd_disk_wal_fsync_duration_seconds_sum 0.3880873379999999
etcd_disk_wal_fsync_duration_seconds_count 55

Il existe aussi des statistiques concernant le quota, comme :

• etcd_server_quota_backend_bytes : quota défini sur le cluster ;
• etcd_mvcc_db_total_size_in_use_in_bytes : la taille de l’espace de stockage logique ;
• etcd_mvcc_db_total_size_in_bytes (ou etcd_debugging_mvcc_db_total_size_in_bytes avant la version 3.4) : taille de l’espace de stockage physique en incluant l’espace libre récupérable par une défragmentation.

Par exemple:

$ curl -s -X GET http://10.0.0.11:2379/metrics | grep \
  -e "^etcd_server_quota_backend_bytes" \
  -e "^etcd_mvcc_db_total_size_in_bytes" \
  -e "^etcd_mvcc_db_total_size_in_use_in_bytes"
etcd_mvcc_db_total_size_in_bytes 1.081344e+06
etcd_mvcc_db_total_size_in_use_in_bytes 1.077248e+06
etcd_server_quota_backend_bytes 5.36870912e+08

Et encore, des statistiques concernant le réseau, préfixées par etcd_network_, par exemple :

• peer_sent_bytes_total : quantité de données envoyées aux autres serveurs, répartie par ID (en byte).
• peer_received_bytes_total : quantité de données reçues des autres serveurs, répartie par ID (en byte).
• peer_sent_failures_total : nombre d’échecs d’envoi vers les autres serveurs, réparti par ID.
• peer_received_failures_total : nombre d’échecs de réception depuis les autres serveurs, réparti par ID.
• peer_round_trip_time_seconds : histogramme des temps d’aller-retours vers les autres membres.

En voici un exemple écourté :

$ curl -s -X GET http://10.0.0.11:2379/metrics | grep -e "^etcd_network_.*\s"
etcd_network_active_peers{Local="3e2cecbaad2c97d4",Remote="8db8de0f2f58d643"} 1
etcd_network_active_peers{Local="3e2cecbaad2c97d4",Remote="fdcf639378827052"} 1
etcd_network_client_grpc_received_bytes_total 534
etcd_network_client_grpc_sent_bytes_total 4.199389e+06
etcd_network_disconnected_peers_total{Local="3e2cecbaad2c97d4",Remote="8db8de0f2f58d643"} 1
etcd_network_disconnected_peers_total{Local="3e2cecbaad2c97d4",Remote="fdcf639378827052"} 1
etcd_network_peer_received_bytes_total{From="0"} 856980
etcd_network_peer_received_bytes_total{From="fdcf639378827052"} 5.39147414e+08
etcd_network_peer_round_trip_time_seconds_bucket{To="8db8de0f2f58d643",le="0.0001"} 0
[…]
etcd_network_peer_round_trip_time_seconds_bucket{To="8db8de0f2f58d643",le="3.2768"} 794
etcd_network_peer_round_trip_time_seconds_bucket{To="8db8de0f2f58d643",le="+Inf"} 794
etcd_network_peer_round_trip_time_seconds_sum{To="8db8de0f2f58d643"} 2.489237533999997
etcd_network_peer_round_trip_time_seconds_count{To="8db8de0f2f58d643"} 794
etcd_network_peer_round_trip_time_seconds_bucket{To="fdcf639378827052",le="0.0001"} 0
[…]
etcd_network_peer_round_trip_time_seconds_bucket{To="fdcf639378827052",le="3.2768"} 794
etcd_network_peer_round_trip_time_seconds_bucket{To="fdcf639378827052",le="+Inf"} 794
etcd_network_peer_round_trip_time_seconds_sum{To="fdcf639378827052"} 2.558094078999999
etcd_network_peer_round_trip_time_seconds_count{To="fdcf639378827052"} 794
etcd_network_peer_sent_bytes_total{To="8db8de0f2f58d643"} 428400
etcd_network_peer_sent_bytes_total{To="fdcf639378827052"} 6.036105e+06
etcd_network_snapshot_receive_inflights_total{From="fdcf639378827052"} 0
etcd_network_snapshot_receive_success{From="fdcf639378827052"} 1
etcd_network_snapshot_receive_total_duration_seconds_bucket{From="fdcf639378827052",le="0.1"} 0
[…]
etcd_network_snapshot_receive_total_duration_seconds_bucket{From="fdcf639378827052",le="+Inf"} 1
etcd_network_snapshot_receive_total_duration_seconds_sum{From="fdcf639378827052"} 25.882678753
etcd_network_snapshot_receive_total_duration_seconds_count{From="fdcf639378827052"} 1

Il est important de superviser etcd car les indisponibilités d’etcd impactent directement la disponibilité des bases de données PostgreSQL contrôlées par Patroni.

health check

Le endpoint /health permet de vérifier que le cluster est en bonne santé, c’est-à-dire qu’il a un leader.

Sur les bases de la réplication physique de PostgreSQL, Patroni fournit un modèle de gestion d’instances, avec bascule automatique et configuration distribuée.

Les tâches nécessaires pour la bascule ou la promotion, l’ajout d’un nouveau nœud, la resynchronisation suite à une défaillance, deviennent la responsabilité de Patroni qui veille à ce que ces actions soient effectuées de manière fiable, en évitant toujours la multiplicité de nœuds primaires (split-brain).

Dans ce module, nous décrivons l’architecture de cette solution de haute disponibilité de service et sa mise en œuvre.

Patroni

Patroni assure la haute disponibilité d’un service PostgreSQL.

L’application des modifications de la configuration de PostgreSQL est effectuée par Patroni qui se charge de la répercuter sur tous les nœuds.

DCS

Patroni s’appuie sur un gestionnaire de configuration distribuée (DCS) pour partager l’état des nœuds de son agrégat et leur configuration. Dans ce module, nous utilisons etcd comme DCS.

Notre but étant la haute disponibilité, etcd ne doit pas devenir un SPOF (single point of failure). Il doit donc lui aussi être déployé en agrégat afin d’assurer une tolérance aux pannes et une disponibilité maximale du service. Un agrégat etcd utilise le protocole RAFT pour assurer la réplication et cohérence des données entre ses nœuds.

Nous sommes donc en présence de deux agrégats de serveurs différents :

• l’un pour les nœuds etcd ;
• l’autre pour les nœuds Patroni gérant chacun une instance PostgreSQL.

Horloges système

La synchronisation des horloges de tous les serveurs Patroni et etcd est primordiale. Elle doit idéalement être assurée par le protocole NTP³.

Les ralentissements causés par les snapshot de sauvegardes des machines virtuelles illustrent ce type de problème. Une indisponibilité (freeze) trop grande peut entraîner un décalage d’horloge trop important, une bascule automatique et une désynchronisation du nœud retardataire. Celui-ci est alors dans l’impossibilité de se raccrocher au nouveau primaire et sa reconstruction est inévitable.

L’anomalie se signale par exemple dans les traces d’etcd par le message :

etcd: the clock difference […] is too high

Patroni est un script écrit en Python. Il permet de maintenir un agrégat d’instances PostgreSQL en condition opérationnelle et de le superviser afin de provoquer une bascule automatique en cas d’incident sur le primaire.

Il s’agit donc d’un outil permettant de garantir la haute disponibilité du service de bases de données.

Patroni est un script Python qui s’appuie sur la capacité de l’écosystème PostgreSQL à répliquer les modifications et les rejouer sur un stockage clé valeur distribué pour garantir la haute disponibilité de PostgreSQL.

Outils :

La réplication physique fournie avec PostgreSQL assure la haute disponibilité des données. Des outils fournis avec PostgreSQL comme pg_rewind et pg_basebackup sont utilisés pour construire ou reconstruire les instances secondaires. Nous les décrivons dans le module de formation I4.

Cette capacité est étendue grâce à la possibilité d’utiliser des outils de la communauté comme barman, pgBackRest ou WAL-G.

DCS (etcd) :

Patroni s’appuie sur un gestionnaire de configuration distribué (DCS) pour partager l’état des nœuds de son agrégat et leur configuration commune.

Nous ne mentionnerons dans ce document que etcd, mais il est cependant possible d’utiliser un autre DCS tel que Consul, ZooKeeper ou même Kubernetes. Tous peuvent être déployés en haute disponibilité de service.

L’automatisation de la prise de décision de bascule est protégée par un mécanisme de verrou partagé appelé leader lock. Ce verrou est attribué à une seule instance secondaire suite à une élection basée sur sa disponibilité et son LSN courant (Log Sequence Number, ou position dans le flux des journaux de transaction).

La présence de deux primaires dans un agrégat d’instance nous amène à une situation que nous voulons éviter à tout prix : le split-brain.

La situation d’un split-brain est obtenue lorsque l’élection automatique d’un primaire est possible sur deux nœuds différents, au même moment.

Les données insérées sur les deux nœuds doivent faire l’objet d’un arbitrage pour départager lesquelles seront gardées lors du rétablissement d’une situation normale (un seul primaire).

La perte de données est plus probable lors de cet arbitrage, suivant la quantité et la méthode d’arbitrage.

Le service peut souffrir d’une indisponibilité s’il y a nécessité de restauration partielle ou totale des données.

L’attribution unique d’un verrou appelé leader lock par Patroni permet de se prémunir d’un split-brain. Ce verrou est distribué et stocké dans le DCS.

Une fois ce verrou obtenu, le futur primaire dialogue alors avec les autres nœuds Patroni référencés dans le DCS, et valide sa promotion en comparant leur type de réplication (synchrone ou asynchrone) et leur LSN courant.

La promotion provoque la création d’une nouvelle timeline sur l’instance primaire et la chaîne de connexion (primary_conninfo) utilisée par les instances secondaires pour se connecter au primaire est mise à jour.

Les secondaires se raccrochent ensuite à la timeline du primaire.

Chaque nœud est en communication régulière avec l’agrégat etcd afin d’informer le système de sa bonne santé. Le primaire confirme son statut de leader et les secondaires celui de follower.

Lorsque la confirmation du leader ne vient pas, un timeout est atteint sur les followers Patroni, déclenchant alors une procédure de bascule.

L’opération de bootstrap consiste à créer ou recréer l’instance PostgreSQL d’un nœud à partir du nœud primaire, d’une sauvegarde ou avec initdb (premier nœud). Par défaut, Patroni créé la première instance avec initdb et lance un pg_basebackup pour créer les réplicas.

Cependant, cela n’est pas toujours souhaitable, notamment sur des gros volumes. Il est alors possible de paramétrer Patroni pour utiliser un autre outil de restauration de sauvegarde PITR, tel que pgBackrest.

Pour reconstruire un nœud ayant pris trop de retard, pgBackrest permet de raccrocher rapidement une instance ayant un volume de données important grâce à la restauration en mode delta.

Le but de configurer un deuxième site est de disposer d’une tolérance de panne à l’échelle d’un site. En cas d’incident majeur, le deuxième site est censé prendre la relève.

Cependant, dans le cas d’un agrégat étendu sur deux sites, il devient impossible de différencier la perte totale d’une salle distante d’une coupure réseau locale. Il est tentant de « favoriser » une salle en y positionnant une majorité de nœuds de l’agrégat, mais cette approche réduit au final la disponibilité de service. Détaillons :

• Cas 1 : primaire et majorité sur le site A
  • si perte du site A : le site B n’a pas le quorum, pas de bascule
  • si perte du site B : aucun impact sur le primaire
• Cas 2 : primaire sur le site A, majorité sur le site B
  • si perte du site A : bascule vers le site B
  • si perte du site B : perte du quorum, l’instance passe en mode stand-by sur le site 0

Dans le cas d’un agrégat multisite, la réponse à cette problématique est d’utiliser au minimum trois sites. En cas de perte de réseau d’un des sites, ce dernier perd alors le quorum et les instances PostgreSQL ne peuvent y être qu’en standby. Les deux autres sites continuent à communiquer entre eux et conservent ainsi le quorum. L’instance primaire peut être démarrée ou maintenue sur l’un de ces deux sites sans risque de split-brain.

Quorum de sites

La présence de trois sites permet de disposer de suffisamment de nœuds pour construire le quorum nécessaire à la bascule automatique.

En effet, on a vu que pour départager deux sites en concurrence, il est nécessaire de disposer d’un arbitre externe et donc d’un troisième site.

Tolérance de panne accrue

La tolérance de panne peut être bien plus importante si l’on décide de prévoir la perte totale de deux sites sur les trois, mais elle apporte une complexité supplémentaire et ne permet pas un automatisme complet jusqu’au bout (après la perte de deux sites).

À tout moment, le maintien du service nécessite de disposer de :

• un nombre suffisant de nœuds pour le DCS, plus précisément d’un quorum de nœuds fonctionnels, ce qui dépend du nombre total de nœuds déclarés dans l’agrégat et de leur répartition entre les trois sites ;
• suffisamment de nœuds Patroni sur chaque site, pour que malgré la perte totale d’un ou deux sites, nous puissions disposer d’une tolérance de panne minimale, sur chaque site.

En conséquence, une solution hautement disponible peut être de disposer de trois nœuds pour le DCS et de deux nœuds Patroni au minimum, ceci pour chaque site.

Changement de site lors des bascules

Lors de la bascule automatique, Patroni décide de privilégier les nœuds les plus à jour avec le primaire, puis les plus réactifs. Il n’y a donc aucune garantie que dans certaines conditions particulières, un nœud d’un autre site soit promu plutôt qu’un nœud géographiquement local.

Perte de deux sites sur trois

S’il ne reste plus qu’un site disponible, promouvoir un de ses nœuds secondaires ne pourra être fait qu’après plusieurs opérations manuelles visant à reconstruire un quorum ⁴ de nœuds dans le DCS en enlevant les nœuds défaillants de sa liste (les nœuds des deux autres sites).

Troisième site en standby

Une autre possibilité consiste à garder le troisième site en dehors du mécanisme de bascule automatique. Il est prévu de ne le solliciter que manuellement, après avoir constaté la perte totale des deux premiers sites.

Patroni est empaqueté pour les principales distributions Linux existantes, qu’elles soient dérivées d’Entreprise Linux (Red Hat, Rocky Linux…) ou de Debian. L’installation ne dure que quelques minutes.

Bien entendu, Patroni a besoin des binaires de PostgreSQL afin d’administrer une instance locale. Utilisez votre méthode favorite ou consultez les méthodes recommandées dans notre module sur l’installation.

Les paquets Patroni sont disponibles pour les distributions Entreprise Linux depuis les dépôts communautaires PGDG. Ceux-ci utilisent par ailleurs des dépendances provenant du dépôt EPEL.

Il faut donc au préalable installer les paquets suivants sur tous les nœuds :

• epel-release
• sur EL 7 : https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
• sur EL 8 : https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm
• sur EL 9 : https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

Pour plus d’information à propos des dépôts PGDG, voir : https://yum.postgresql.org/howto/

Sur chaque nœud PostgreSQL, nous pouvons désormais installer Patroni :

dnf install -y patroni-etcd

Notez que ce paquet installe les paquets patroni et python3-etcd par dépendance, ce dernier étant la librairie cliente d’etcd en python. Il n’installe pas la partie serveur d’etcd, cette-ci devant idéalement être située sur des nœuds distincts.

Pour plus d’information à propos de l’installation d’un cluster etcd, voir le module de formation etcd : Architecture et fonctionnement.

Debian et ses dérivés incluent directement Patroni et etcd dans ses dépôts officiels. Néanmoins, étant donné la politique de gestion des versions des paquets Debian, les versions de Patroni peuvent rapidement être désuètes.

De nouvelles versions de Patroni sont régulièrement publiées, incluant des corrections, améliorations et nouveautés. C’est pourquoi nous vous recommandons d’utiliser autant que faire se peut une version récente.

Pour se faire, nous proposons d’installer les dépôts PGDG avant d’installer Patroni sur les nœuds PostgreSQL :

# apt install postgresql-common gnupg
# /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh -y
# apt install -y patroni

Pour les autres distributions Linux ou si certaines contraintes vous empêchent d’utiliser les méthodes précédentes, il est possible d’installer Patroni grâce au gestionnaire de paquets Python pip.

Le nom du paquet Python à installer est patroni. Cependant, si vous utilisez cette méthode manuelle, il vous sera probablement aussi nécessaire de spécifier la dépendance sur le DCS à utiliser, ici etcd, avec le format patroni[etcd]. Par exemple :

pip install patroni[etcd3]

Vous trouverez la liste des dépendances disponibles dans la documentation de Patroni : https://patroni.readthedocs.io/en/latest/installation.html#general-installation-for-pip

La configuration de patroni est répartie sur trois niveaux différents.

La configuration statique peut désigner soit un fichier YAML, soit un répertoire. Les fichiers par défaut sont /etc/patroni/config.yml sous Debian et dérivés et /etc/patroni/patroni.yml sous les EL et dérivés.

Si un répertoire est spécifié, tous les fichiers YAML du répertoire seront chargés dans l’ordre où ils apparaissent. Si des paramètres sont définis deux fois, seule la dernière valeur est prise en compte.

Les modifications faites dans la configuration statique peuvent être chargées par l’une des méthodes suivantes :

• le rechargement du service (si disponible) ;
• la commande patronictl reload ;
• un signal SIGHUP (reload) au processus patroni.

patroni --generate-sample-config /chemin/vers/fichier.yml

Les éléments de configuration suivants sont présents dans ce fichier :

• configuration de l’API REST de Patroni (section restapi) ;
• configuration des interactions avec un des DCS supporté, dont etcd (section etcd ou etcd3 pour ce dernier) ;
• configuration des interactions avec PostgreSQL (section postgresql) et de sa configuration (postgresql.conf, pg_hba.conf, pg_ident.conf) ;
• configuration du watchdog ;
• configuration concernant la création de l’instance (section bootstrap).

Toutes les informations présentes dans la section bootstrap sont uniquement utilisées lors de la création du cluster. Cela inclut la configuration dynamique qui est dans la section bootstrap.dcs, mais aussi la configuration de PostgreSQL effectuée dans les sections bootstrap.initdb, bootstrap.method, bootstrap.pg_hba, bootstrap.users.

Les modifications des autres sections de cette configuration doivent être reportées dans le fichier de configuration de tous les nœuds si l’on souhaite qu’elles soient prises en compte globalement. Cela peut être fait avec des outils d’industrialisation comme Ansible, Chef,…

Le fichier de configuration peut être testé avec l’exécutable de Patroni :

patroni --validate-config /etc/patroni/config.yml

Le second niveau de configuration est la configuration dynamique. Elle est initialisée grâce aux données de la section bootstrap.dcs du fichier de configuration YAML. Elle est chargée dans le DCS et n’est plus maintenue qu’à cet endroit. Les modifications doivent être faites avec la commande patronictl edit-config. Patroni copie cette configuration à intervalle régulier dans le fichier patroni.dynamic.json placé dans le répertoire de données de l’instance.

Pour finir, certains éléments de configuration peuvent être spécifiés via des variables d’environnement. Les variables d’environnement ont toujours précédence sur les fichiers de configuration.

L’application de la configuration locale ou dynamique de PostgreSQL suit l’algorithme suivant :

• SI postgresql.custom_conf est défini dans la configuration YAML de patroni
  • ALORS le fichier configuré dans custom_conf sera utilisé comme référence de configuration en lieu et place de postgresql.base.conf et postgresql.conf
  • SINON SI le fichier postgresql.base.conf existe
    • ALORS il sera utilisé comme référence de la configuration
    • SINON le fichier postgresql.conf est utilisé et renommé en postgresql.base.conf
• La configuration dynamique est écrite dans postgresql.conf à l’exception de certains paramètres qui seront passés directement en paramètre du postmaster (voir plus loin).
• Un include vers la configuration de référence est ajouté au fichier postgresql.conf
• SI des paramètres nécessitent un redémarrage (pg_settings.context)
  • ALORS un flag pending_restart est donné au nœud et sera retiré lors du prochain redémarrage.

L’ordre de prise en compte des paramètres de Postgresql est donc le suivant :

1. paramètres présents dans postgresql.base.conf ou spécifiés dans custom_conf ;
2. paramètres présents dans postgresql.conf ;
3. paramètres présents dans postgresql.auto.conf ;
4. paramètres défini au lancement de PostgreSQL avec l’option -o --name=value.

Les paramètres globaux (de premier niveau) de la configuration de Patroni sont :

name:

Le nom de l’hôte, doit être unique au sein du cluster.

namespace:

Le chemin dans lequel est stockée la configuration de Patroni dans le DCS, par défaut: /service.

scope:

Le nom de l’agrégat, utilisé dans les commandes patronictl et pour stocker la configuration de l’agrégat dans le DCS. Ce paramètre est requis et doit être identique sur tous les nœuds.

Exemple de fichier de configuration :

name: p1
scope: acme
[…]

Et voici un exemple de l’arborescence créée dans le DCS pour la configuration ci-dessus et avec deux serveurs p1 et p2 :

$ ETCDCTL_API=3 etcdctl get --prefix / --keys-only
/service/acme/config
/service/acme/initialize
/service/acme/leader
/service/acme/members/pgsql0.hapat.vm
/service/acme/members/pgsql1.hapat.vm
/service/acme/status

Patroni supporte six types de DCS différents : etcd, Consul, Zookeeper, Exhibitor, Kubernetes.

Dans cette formation, nous n’abordons que l’utilisation d’etcd, qui dispose de deux sections en fonction de la version du protocole d’etcd utilisée :

• etcd pour le protocole v2 ;
• etcd3 pour le protocole v3.

L’API v3 est configurée par défaut dans etcd depuis qu’il est en version 3.4. Son implémentation dans Patroni est considérée comme stable pour la production depuis sa version 2.1.5. Il est recommandé de l’utiliser lorsque les versions utilisées le permettent car l’API v2 est progressivement dépréciée :

• elle est désactivée par défaut depuis la version 3.4 d’etcd
• elle sera supprimée dans la version 3.6 d’etcd

Les paramètres suivants permettent de configurer l’accès au DCS :

host et hosts:

Permettent de définir au choix un ou une liste de nœud etcd au format host:port.

protocol:

Le protocole utilisé parmi http et https, par défaut à http.

username:

Utilisateur pour l’authentification à etcd.

password:

Mot de passe pour l’authentification à etcd.

cacert:

Le certificat du serveur d’autorité de certification, active le SSL si présent.

cert:

Certificat du client.

key:

Clé du client, peut être ignorée si elle fait partie du certificat.

D’autres paramètres sont décrits dans la documentation officielle.

Exemple :

[…]
etcd3:
  hosts:
   - 10.20.89.56:2379
   - 10.20.89.57:2379
   - 10.20.89.58:2379
  username: patroniaccess
  password: secret
[…]

Ci-après un exemple de configuration visible après l’initialisation de l’instance via la commande patronictl show-config :

$ patronictl -c /etc/patroni/config.yml show-config
loop_wait: 10
master_start_timeout: 300
postgresql:
   parameters:
      archive_command: /bin/true
      archive_mode: 'on'
   use_pg_rewind: false
   use_slot: true
retry_timeout: 10
ttl: 30

La configuration du démon Patroni est représentée à la racine de la section bootstrap.dcs puis dans YAML dynamique. Elle comprend les paramètres suivants :

loop_wait:

Temps de pause maximal entre chaque boucle de vérification, par défaut 10s, au minimum 3s. Cela correspond au temps nominal de la boucle de vérification. Un problème au niveau du DCS ou du réseau supérieur ou égal à cette valeur provoque un demote du leader.

ttl:

Temps avant l’initialisation d’un failover, par défaut 30s, au minimum 20s. Cela correspond au temps maximal entre deux mises à jour de la leader key.

retry_timeout:

Temps avant de retenter une action échouée sur PostgreSQL ou le DCS, par défaut 10s, au minimum 3s.

maximum_lag_on_failover:

Limite supérieure du délai (lag), en octets, pour qu’un nœud follower puisse participer à une élection.

max_timelines_history:

Quantité maximale de changements de timeline conservés dans l’historique stocké dans le DCS, par défaut 0. Pour une valeur de 0, Patroni conserve tout l’historique.

master_start_timeout:

Le temps maximal autorisé pour qu’une instance primaire redevienne fonctionnelle suite à un incident, par défaut 300. Si la valeur est nulle et que l’état du cluster le permet, Patroni déclenche un failover immédiat suite à un incident, ce qui peut provoquer une perte de donnée dans le cas d’une réplication asynchrone.

master_stop_timeout:

Le temps maximal autorisé pour l’arrêt de PostgreSQL lorsque le mode synchrone est activé, par défaut à 0. Si la valeur est supérieure à zéro et que le mode synchrone est activé, Patroni envoie un signal SIGKILL au postmaster s’il met trop de temps à s’arrêter.

synchronous_mode:

Activation de la réplication synchrone. Dans ce mode, un ou des secondaires sont choisis comme followers synchrones. Seuls ces secondaires et le leader peuvent participer à une élection.

synchronous_node_count:

Nombre de followers synchrones que Patroni doit chercher à maintenir. Pour cela, Patroni choisit des followers synchrones parmi les secondaires disponibles et valorise le paramètre synchronous_standby_names dans la configuration de PostgreSQL en listant uniquement ces nœuds (ex: 2(p2,p3)). Si un nœud disparaît de l’agrégat, Patroni le retire de synchronous_standby_names. Par défaut, Patroni fait en sorte de ne pas bloquer les écritures en diminuant le nombre de nœuds synchrones jusqu’à désactiver la réplication synchrone si nécessaire. Les followers synchrones sont aussi listés dans l’entrée /namespace/scope/sync de etcd.

synchronous_mode_strict:

Empêche la désactivation du mode synchrone dans le cas où il n’y a plus de follower synchrone. Pour cela, Patroni positionne le paramètre synchronous_standby_names à * quand il n’y a plus de candidats, ce qui bloque les écritures en attendant le retour d’un follower synchrone. Ce paramètre peut donc provoquer une indisponibilité du service.

maximum_lag_on_syncnode:

Limite supérieure du lag en octets au delà de laquelle un nœud follower synchrone est considéré comme non sain et remplacé par un follower asynchrone sain. Une valeur inférieure ou égale à zéro désactive ce comportement. Une valeur trop basse peut provoquer des changements de follower synchrone trop fréquents. Par défaut à -1.

check_timeline:

Vérifie que la timeline du candidat est bien la plus élevée avant d’effectuer la promotion. Désactivé par défaut.

failsafe_mode:

Ce mode permet d’éviter le déclenchement d’une opération de démote sur l’instance primaire lorsque le DCS est indisponible. Pour cela, une nouvelle clé /failsafe est ajoutée au DCS. Elle est maintenue par l’instance primaire et contient la liste des membres autorisés à participer à une élection. En cas de perte du DCS, si tous les membres listés dans la clé failsafe sont joignables, l’instance primaire garde son rôle. Si l’un d’entre eux ne répond pas, l’instance primaire perd son rôle de leader. Désactivé par défaut.

Depuis la version 3.2.0, Patroni s’assure que la règle suivante est valide et que ttl, retry_timeout et ttl respectent les valeurs minimales décrites plus tôt :

loop_wait + 2 * retry_timeout <= ttl

Si cette règle n’est pas respectée, Patroni ajuste le paramétrage en préférant réduire loop_wait, à moins qu’il soit déjà à sa valeur minimale, dans ce cas il diminue retry_timeout :

• SI min_loop_wait + 2 * retry_timeout > ttl ALORS
  • loop_wait = min_loop_wait = 1s
  • retry_timeout = (ttl - min_loop_wait) // 2
• SINON SI loop_wait + 2 * retry_timeout > ttl ALORS
  • loop_wait = ttl - 2 * retry_timeout

La section bootstrap.method permet de décrire la manière dont la première instance du cluster doit être créée. La méthode initdb est la méthode par défaut, mais il est possible d’utiliser d’autres commandes.

L’exemple suivant utilise une sauvegarde pgBackRest pour initialiser le cluster. La commande à utiliser est spécifiée avec le paramètre command. Si l’option no_params est à False les paramètres --scope et --datadir qui définissent respectivement le nom du cluster et le chemin de l’instance seront ajoutés à la commande. Pour finir, le paramètre keep_existing_recovery_conf permet de conserver le recovery.conf généré par pgBackRest.

bootstrap:
   […]
   method: pgbackrest
   pgbackrest:
      command: /bin/bash -c "pgbackrest --stanza=test restore"
      keep_existing_recovery_conf: True
      no_params: True
[…]

Si la méthode initdb est choisie, une section spécifique doit être renseignée pour en modifier les paramètres. Cela permet par exemple de spécifier si les sommes de contrôles doivent être activées (data-checksums) et de définir une locale et un encodage :

bootstrap:
   […]
   # ici la méthode est facultative, initdb est la valeur par défaut
   method: initdb
   initdb:
     - data-checksums
     - encoding: UTF8
     - locale: UTF8
<...>

Les instances secondaires doivent être construites comme des clones de la primaire, une commande spécifique est donc dédié à leur création. Comme ces secondaires peuvent être créés à n’importe quel moment de la vie du cluster, cette commande se situe dans la section postgresql.create_replica_method, conservée dans le DCS.

Cette section peut contenir plusieurs méthodes qui seront testées dans l’ordre d’apparition. Patroni permet l’utilisation de pg_basebackup (par défaut), pgBackRest, WAL-G, barman ou d’un script utilisateur pour réaliser cette opération.

Il est possible de fournir des paramètres à l’outil que l’on souhaite utiliser. Tous les paramètres configurés seront communiqués sous la forme --<nom>=<valeur> ou --<nom>. Trois paramètres sont cependant réservés et ne seront pas passés aux scripts :

no_master:

Permet d’utiliser une méthode même si aucune instance n’est démarrée dans l’agrégat. Désactivé par défaut.

no_param:

Permet de ne pas utiliser les paramètres supplémentaires décrits ci-après. Désactivé par défaut.

keep_data:

Indique à Patroni de ne pas vider le répertoire de données de l’instance avant la réinitialisation. Désactivé par défaut.

Les paramètres suivant seront également fourni au script si l’option no_params reste a False :

scope:

Nom de l’agrégat.

datadir:

Chemin vers le répertoire de donnée de l’instance secondaire.

role:

Toujours valorisé à replica.

connstring:

Chaîne de connexion vers le nœud depuis lequel la copie va être réalisée.

Exemple de configuration (dynamique) des méthodes de création des réplicas :

[…]
postgresql:
    […]
    create_replica_methods:
        - pgbackrest
        - basebackup
    pgbackrest:
        command: /usr/bin/pgbackrest --stanza=patroni_demo --delta restore
        keep_data: True
        no_master: True
        no_params: True
    basebackup:
        keep_data: False
        no_master: False
        no_params: False
        verbose
        max-rate: '100M'
        waldir: /pg_wal/14/pg_wal
    […]

La documentation est disponible à cet emplacement : https://patroni.readthedocs.io/en/latest/replica_bootstrap.html#custom-replica-creation.

La section bootstap.users permet de créer et configurer des rôles PostgreSQL supplémentaires. Elle est dépréciée en 3.2.0 et sera supprimée en 4.0.0.

bootstrap:
   […]
   users:
      admin:
         password: password_admin
         options:
          - createrole
          - createdb
[…]

Enfin, des scripts peuvent être déclenchés après l’initialisation de l’instance avec les sections bootstrap.post_bootstrap ou bootstrap.post_init. Le script reçoit en paramètre une URL de connexion avec comme utilisateur le super utilisateur de l’instance et est appelé avec la variable d’environnement PGPASSFILE positionnée.

La configuration de l’agrégat PostgreSQL à déployer et/ou maintenir peut être chargée dans le DCS au moment de l’initialisation depuis la section bootstrap.dcs.postgresql. Elle est ensuite conservée dans le YAML dynamique dans la section postgresql. Cette section permet d’avoir une configuration commune pour toutes les instances. Les paramètres suivants sont disponibles à ce niveau :

connect_address:

Adresse IP locale sur laquelle PostgreSQL est accessible pour les autres nœuds et applications utilisés au sein du cluster, sous la forme [IP|nom d'hôte]:port.

data_dir:

Emplacement du répertoire de données.

config_dir:

L’emplacement des fichiers de configuration, par défaut défini à la valeur de data_dir.

bin_dir:

Chemin vers les binaires de PostgreSQL : pg_ctl, pg_rewind, pg_basebackup et postgres. Si cette valeur n’est pas configurée, la variable d’environnement PATH est utilisée pour trouver les exécutables.

listen:

Liste d’adresses sur lesquelles PostgreSQL écoute. Elles doivent être accessibles par les autres nœuds. Il est possible d’utiliser une liste sous la forme {IP|nom d'hôte}[,…]:port, dans ce cas la première adresse sera utilisée par Patroni pour ses connexions au nœud local. Ce paramètre est utilisé pour valoriser les paramètres listen_addresses et port de PostgreSQL. Il est possible d’utiliser * plutôt qu’une liste d’IP.

use_unix_socket:

Indique à Patroni de préférer une connexion par socket pour accéder au nœud local. Désactivé par défaut.

use_unix_socket_repl:

Permet de dire à Patroni de préférer une connexion par socket pour la réplication. Désactivé par défaut.

pgpass:

Chemin vers un fichier .pgpass. Il est préférable de laisser Patroni gérer ce fichier et de ne pas ajouter nos propres entrées car elles pourraient être supprimées.

recovery_conf:

Configuration supplémentaire à ajouter lors de la configuration d’un nœud follower. Même si le fichier recovery.conf disparaît à partir de la version 12 de PostgreSQL, la section porte toujours ce nom.

custom_conf:

Chemin vers un fichier de configuration a utiliser à la place de postgresql.base.conf. Le fichier doit exister et être accessible par Patroni et PostgreSQL. Patroni ne surveille pas ce fichier pour détecter des modifications et ne le sauvegarde pas. Il est simplement inclus depuis le fichier postgresql.conf.

pg_ctl_timeout

Temps d’attente maximale pour les actions effectuées avec pg_ctl (start, stop, restart), par défaut à 60.

use_slots

Utilisation des slots de réplication, activé par défaut pour les versions de PostgreSQL supérieures à la 9.4.

use_pg_rewind:

Utilise pg_rewind pour reconstruire l’ancien primaire en tant que secondaire après un failover, par défaut à false.

remove_data_directory_on_rewind_failure:

Force la suppression du répertoire de donnée de l’instance en cas d’erreur lors du pg_rewind. Désactivé par défaut.

remove_data_directory_on_diverged_timelines:

Supprime le répertoire de données si les timelines divergent entre le secondaire et le primaire.

pre_promote:

Permet d’exécuter un script pendant un failover après l’acquisition du leader lock et avant la promotion d’un réplica. Si le script renvoie un code différent de zéro, Patroni n’effectue pas la promotion et relâche la leader key. Ce paramètre est principalement utile pour mettre en œuvre un mécanisme de fencing.

Exemple de configuration basique :

<...>
postgresql:
  listen: "*:5432"
  connect_address: 10.20.89.54:5432
  data_dir: /var/lib/pgsql/11/data
  bin_dir: /usr/pgsql-11/bin
  pgpass: /var/lib/pgsql/.pgpass_patroni
  <...>

Plusieurs sous-sections complètent cette configuration de PostgreSQL.

La sous-section postgresql.authentication permet d’indiquer à Patroni quels utilisateurs choisir pour :

• superuser : ses tâches courantes ;
• replication : la configuration de la réplication ;
• rewind : l’exécution de la commande pg_rewind.

Pour chaque type d’utilisateur, les éléments de configuration suivants sont disponibles et correspondent aux paramètres de connexion éponymes : username, password, sslmode, sslkey, sslpassword, sslcert, sslrootcert, sslcrl, sslcrldir, gssencmode et channel_binding.

Exemple de section authentication :

[…]
postgresql:
   […]
   authentication:
      superuser:
         username: patronidba
         password: secret
      replication:
         username: replicator
         password: secretaussi
      rewind:
         username: rewinder
         password: sectrettoujours
   […]

La sous-section postgresql.parameters, contient les paramètres PostgreSQL maintenus par Patroni et stockés dans le DCS de manière inconditionnelle, soit parce que PostgreSQL requiert qu’ils soient identiques partout, soit par choix d’implémentation. Voici la liste de ces paramètres :

max_connections:

Nombre maximal de connexions simultanées, par défaut à 100.

max_locks_per_transaction:

Nombre maximal de verrous par transaction, par défaut à 64.

max_worker_processes:

Nombre maximum de processus worker, par défaut à 8.

max_prepared_transactions:

Nombre maximal de transactions préparées, par défaut à 0.

wal_level:

Niveau de détail des informations écrites dans les WAL, défaut à replica.

wal_log_hints:

Force l’écriture complète d’une page de données lors de sa première modification après un checkpoint, même pour des modifications non critiques comme celles des hint bits. Cela permet l’utilisation de pg_rewind. Activé par défaut.

track_commit_timestamp:

Permet de tracer l’horodatage des commits dans les journaux de transactions. Désactivé par défaut.

max_wal_senders:

Nombre maximal de processus wal sender, par défaut à 5.

max_replication_slots:

Nombre maximal de slots de réplication, par défaut à 5.

wal_keep_segments:

Nombre maximal de WAL conservés pour les instances secondaires afin de les aider à récupérer leur retard, par défaut à 8. Disponible jusqu’en PostgreSQL 12.

wal_keep_size:

Quantité de WAL conservés pour les instances secondaires afin de les aider à récupérer leur retard, par défaut à 128MB. Disponible à partir de PostgreSQL 13.

listen_addresses:

La ou les interfaces sur lesquelles PostgreSQL écoute. Ce paramètre est défini via le paramètre postgresql.listen ou la variable d’environnement PATRONI_POSTGRESQL_LISTEN.

port:

Le port sur lequel écoute l’instance, lui aussi défini par le paramètre postgresql.listen ou la variable d’environnement PATRONI_POSTGRESQL_LISTEN.

cluster_name:

Permet de définir le nom de l’instance qui sera affiché dans la description des processus (eg. par la commande ps). Il est défini en fonction de la valeur du paramètre scope ou de la variable d’environnement PATRONI_SCOPE.

hot_standby:

Permet d’ouvrir les instances secondaires en lecture seule. Activé par défaut.

Afin que ces paramètres ne puissent pas être modifiés via les fichiers de configuration, ils sont passés en paramètre de la commande de démarrage de PostgreSQL. Ce n’est le cas que pour la liste ci-dessus. Les autres paramètres présents dans la section postgresql.parameters sont appliqués de manière classique en suivant la hiérarchie décrite précédemment.

Les sous-sections postgresql.pg_hba et postgresql.pg_ident contiennent chacune une liste de règles à ajouter aux fichiers respectifs, dans leurs formats respectifs. Voir l’exemple ci-après.