Salut,

notice: dev PAF et j'aime la HA

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

Bon courage !

Salut,

Je l'utilise principalement pour les mises à jour majeure.

Dans les autres cas, je lui préfère la répli logique quand c'est possible...sauf que je n'ai pas eu d'autres cas depuis que la répli logique existe

C'est moins complet, mais beaucoup plus simple.

++

bonjour,

Je ne sais pas quelle procédure vous suivez, mais je ne vois pas le lien entre votre service PostgreSQL non démarré et le fait de (probablement) le détruire en utilisant l'outil pg_resetxlog.

Oubliez cet outil pour le moment, faite comme si vous n'en avez jamais entendu parlé.

Donnez plus de détails si vous en avez.

Salut,

Il est aussi possible d'utiliser l'excellent pgTap pour effectuer ces tests là. Voir: http://pgtap.org/documentation.html

D'autant plus que si vous migrez une application, je suis certain que quelques tests de non régression écrits avec pgTap ne seront pas de trop

++

Excellent, heureux que tout fonctionne bien. L'apprentissage de Pacemaker est un peu rude, mais ensuite, c'est juste plaisant effectivement

Rendons à César ce qui appartient à César. La promotion d'un standby en une commande, sans PAF et sans coupure, c'est un simple "pg_ctl promote"

En revanche, pour ce cas bien précis, si c'est Pacemaker/PAF qui est au commande, alors il faut demander à PAF de le faire pour vous, bien entendu, donc avec pcs.

Bonne continuation !

Excellent !

Bonjour,

D'après les log, pgsqlms n'arrive pas à se connecter à l'instance (il utilise "pg_isready") et pourtant "pg_ctl" lui indique bien que l'instance est démarrée ("postmaster.pid" présent et correspond bien à un processus postgres).

Je pense donc que pgsqlms n'arrive simplement pas à se connecter aux instances. Soit car il tente de se connecter au mauvais endroit, soit à cause d'un firewall (impossible si via le socket).

Je constate que le bout de conf que vous présentez à propos du socket est commenté. Néanmoins, il se peut tout à faire le socket soit bien situé dans "/tmp" (emplacement par défaut utilisé par pgsqlms). Avez-vous bien vérifié que tout est OK de ce coté là ?

Notez que si pouj-pgsql-5 est déclaré comme slave, c'est simplement car il n'existe aucune possibilité de l'isoler. Le nœud est bien marqué UNCLEAN et pgsqld FAILED (car pgsqlms n'a probablement pas pu s'y connecter donc).

Bonjour,

Et pourquoi pas une seule base, mais avec un schéma pas cabinet. C'est l'équivalent de votre dernière option, mais sans préfixer les tables. Chaque cabinet a ses propres tables, "isolées" dans un schéma propre avec au besoin ses droits particuliers.

Cette approche vous permettra  par exemple d'intégrer les données de plusieurs cabinets à la fois dans la même requête, sans difficultés (pour des besoins de reporting par exemple).

Voir: https://www.postgresql.org/docs/current … hemas.html

Bonjour,

De mon coté, ext4 ou xfs indifféremment, sur LVM.

Et voilà donc une béta de sortie: https://github.com/dalibo/PAF/releases/tag/v2.2_beta1

Comme tu sembles être concerné par l'une des nouvelles fonctionnalité, ton retour sur tes tests serait la bienvenue !

Merci !

Note que le "gros" patch pg10 n'est pas encore mergé dans la branche maser de PAF, il est relativement fiable de se lancer sur la version de dev actuellement, d'autant plus si la fin de ton projet est prévu dans plusieurs semaines/mois, où PAF 2.2 sera probablement déjà publié.

Bonjour Sébastien,

PAF 2.1 ne supporte pas d'avoir plusieurs ressources dans le cluster utilisant le même agent.

Cela a néanmoins été corrigé dans le dépôt de PAF et sera donc publié avec la version 2.2 très prochainement avec au passage le support de pg10 (je lutte un peu sur l'installation des pages de manuels et ce sera publié ensuite).

La meilleure approche pour moi est donc de créer une ressource par instance, avec une IP secondaire par master qui se promène dans le cluster...le tout avec la prochaine version de PAF donc.

Ceci dit, il est relativement dangereux d'installer plusieurs instances dans un même cluster: si l'une a une défaillance nécessitant un, fencing du nœud, l'autre sera emporté avec...