Vous trouverez en ligne les différentes versions complètes de ce document.

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.

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.