Je suis en train de voir ce qui est déployable sans licence …
- pg-ii pool ?
On utilise la solution de zalando https://github.com/zalando/patroni sur kubernetes avec l’operator https://github.com/zalando/postgres-operator
je sais pour indie, j’ai papoté avec Pierre (salut!).
Il me « met dans un sacré pétrin » (lol) lui, car votre truc c’est top, c’est une autre vue du SI !
Mais personne n’est prêt à ce genre de techno … dans mon taf.
Et franchement je n’avais pas envisager de pousser le truc des conteneurs aussi loin …
Pas de bol maintenant que j’ai bien lu pas mal de truc sur ces technos : je sais . arhhhgggggggghh.
(c’est un peu pilule bleu pilule rouge « votre » truc !)
Le gros point noir (de mon point de vue et de mon chef de pôle) c’est cette encapsulation démentielle. On déporte toute l’infra dans un logiciel, une seule techno … Kubernetes.
Donc gros dilemme pour moi.
Eeheh 
Patroni est kubernetes et container agnostic.
Au moins comme ca vous ne serez pas dépaysé quand vous serez décidés 
Pour le coup très satisfait de patroni, utilisez en prod par zalendo. C’est du costaud
Je rapporte ici les suggestions d’un dba , « ioguix » du forum https://forums.postgresql.fr
Les deux solutions viables actuelles sont Patroni et Pacemaker/PAF, pour une raison claire: ils font de la HA correctement et pas avec des bouts de scotch ou en laissant l’administrateur développer lui même les points critique de l’archi.
Repmgr ou pgPool ne supportent ni le fencing, ni le watchdog, ni de (vrai) quorum. Ils nécessitent de fournir des scripts où vous aurez à gérer ce type de notions vous même. Des notions dev et maintenues par des experts en HA depuis plus de dix ans dans Pacemaker. Vous n’obtiendrez jamais quelque chose de propre et fiable. Néanmoins, si vous avez précisément identifié les différents cas où l’outil n’est pas capable de gérer correctement une bascule, que vous acceptez ce risque et que vous avez bien tout documenté, alors pourquoi pas.
Concernant repmgr, le witness n’est pas un vrai qorum. Chaque nœud dans son coin décide de quand il faut faire une élection. Sur ce point, c’est déjà un peu risqué. Ensuite, si il « voit » le witness, il le compte d’office pour une voix dans son calcul. Le witness est complètement passif. On pourrait le comparer au qdevice dans une stack Pacemaker, sauf que le qdevice prend réellement part à l’élection et décide à qui il donne sa voix en fonction de l’algo choisi. Mais bon, contrairement à pgPool, on peut éventuellement construire une stack repmgr convenable avec beaucoup d’investissement et une surcouche de développement importante pour fiabiliser la chose au maximum. Reste ensuite à documenter ce qui ne va pas, comme d’hab.
Patroni ne supporte pas le fencing. Mais lui, il a un vrai quorum grâce au cluster DCS (à monter de préférence à part) et surtout supporte le watchdog. Une stack Patroni saine active le watchdog. Il y a deux/trois petits détails (peu significatifs) dans Patroni qui me font malgré tout préférer Pacemaker. En outre, la gestion d’une vIP pour atteindre le primaire est plus complexe qu’il n’y parait. Du coup, utilisez HAProxy, mais ça rajoute un service à gérer dans votre stack…Ou collez l’intelligence dans la couche applicative si vous le pouvez, mais votre archi devient invasive coté applicatif. Nous avons creusé vip-manager ces derniers temps, plutôt une bonne idée, mais le diable se cache dans les détails. Bref, Ici aussi, tant qu’on a conscience des failles possibles de son archi et que c’est documenté, on peut dormir sur ses deux oreilles. Moi, je dors mieux en sachant Patroni/DCS aux manettes qu’avec l’un des deux précédents. Surtout quand un watchdog est prêt à te coller un reset derrière les oreilles si ton process n’est pas obéissant 
Enfin, Pacemaker supporte le fencing, le quorum, le watchdog, le qdevice ou encore le storage base death (sbd). Avec tout ça, vous pouvez construire tout pleins d’archis fiables différentes et rigolotes (j’en fait trop ?) en fonction de vos moyens, matériel dispo, équipes concernées, etc:
- un cluster 2 nœuds FIABLE avec quorum (un peu spécial) et fencing quand on est serré en nombre de machine
- l’équivalent de Patroni avec 2+ nœuds + un qdevice (capable de participer à plusieurs clusters comme un cluster DCS)
- un cluster shared storage, simple et efficace si bien construit
- un cluster shared nothing avec PAF, pas très compliqué à monter et efficace si bien construit
- du poison pill pour le fencing si vous avez du stockage accessible depuis tous les nœuds (sbd)
- …
Mais c’est bien là le problème de Pacemaker. Il propose de gérer la HA de tout type de services, le plus correctement possible. La HA et toutes ces notions sont complexes, donc Pacemaker est complexe et on se perd dans la jungle des notions et possibilités. Mais une fois l’archi construite et comprise, c’est que du bonheur. En échange:
- gérer une vIP avec Pacemaker, c’est 4 lignes de définition (https://clusterlabs.github.io/PAF/Quick … -resources). Nous n’avons toujours pas trouver comment faire fiable avec les autres solutions.
- une bascule de rôle se fait en une commande, sans redémarrage des standby
- pas de split brain possible
- un projet activement développé par RedHat, Suse, Linbit et hastexo
- du support professionnel coté système (RH et Suse entre autre)
- paquets dispos et à jour sur toutes les distro Linux de bon goût (utilisez pcs!)
- intégrer HAProxy au dessus de votre stack Pacemaker (inutile de l’y intégrer), c’est aussi complexe qu’avec Patroni. Pas plus pas moins. Bienvenue la répartition de charge
Bref, je suis biaisé, c’est évident. Plus je creuse Pacemaker, plus je découvre sa souplesse et sa robustesse. Sans parler de sa petite communauté bienveillante et accueillante. On peut éventuellement lui reprocher de ne pas avoir assez de documentation, mais nous avons tenté d’y répondre un peu dans la doc PAF…et nous devrions encore ajouter des pages de doc.
Concernant Patroni, il est simple et fiable et je l’aime aussi pour ça. Mais pour être juste dans la comparaison, il faut aussi compter la montée en compétence sur le DCS choisi (mais parfois déjà présent dans le réseau) et l’ajout au dessus d’autres briques (eg. HAProxy, confd). Reste que se prendre des backtrace python sur de la prod (coté cli ou daemon) ça peut parfois effrayer un peu 
(rare hein, mais par exemple: https://github.com/zalando/patroni/issues/1418)
Quelque soit l’outil choisi, vous ne devez pas faire l’économie de tests poussés, de torture de votre cluster, de tout documenter, d’écrire toutes les procédures, de penser à vos backups, de prévenir l’équipe réseau, l’équipe SAN, les dev ou devops. Bref, préparez-vous à l’imprévisible