Forums PostgreSQL.fr

dangil

Membre

Outils de failover automatique

Bonjour,

Pourriez-vous me dire quel est l'outil le plus approprié et peut être le plus simple à utiliser et configurer ;-) pour surveiller un environnent haute disponibilité (1 master et 1 slave) et qui pourra effectuer un failover automatique et cas de crash du master ?

Nous allons installer cet environnement sous postgres 9.3 en streaming replication.

Merci d'avance pour vos réponses et salutations
Daniel

Marc Cousin

Membre

Re : Outils de failover automatique

Bonjour,

Simple et haute disponibilité, ça ne va pas vraiment ensemble. Il y a trop de choses à maîtriser pour espérer poser une solution et qu'elle marche toute seule.

Pour moi les deux plus abouties en ce moment sont repmgr http://www.repmgr.org/ et PAF http://dalibo.github.io/PAF/

Elles ont chacune leurs avantages et leurs inconvénients. Mais il n'y a pas de solution magique… Faire un failover automatique en cas de crash du master, ça a l'air simple, mais ça veut dire, si on veut garantir l'intégrité de l'ensemble, pouvoir garantir que le maître a vraiment un problème. Ça veut aussi dire pouvoir garantir qu'il ne redeviendra pas disponible de lui-même après le crash, et n'assurer la promotion de l'esclave qu'à ce moment là… voire ne pas faire de promotion dans le doute, et attendre l'administrateur. Et il y a vraiment beaucoup de cas d'erreur possibles…

Dernière modification par Marc Cousin (29/09/2016 16:10:22)

---

Marc.

yohmartin

Membre

Re : Outils de failover automatique

Bonjour, il y aussi pgpool, qui permet de mettre en place une vip avec bascule automatique.
Ca marche pas mal.
Mais il faut toujours surveiller si il ya eu des bascules ou non

Marc Cousin

Membre

Re : Outils de failover automatique

Désolé, je vais avoir l'air de dénigrer, mais pgpool est une très mauvaise idée (d'expérience).

Ça dégrade les performances de façon très notable (mesuré à ~ 30% chez certains clients, entre autres parce qu'on  passe par deux parsers postgresql au lieu d'un). Il fait mal le pooling (pgbouncer fait ça mieux), il fait mal la bascule automatique (plein de bugs), ça rajoute un SPOF (à moins de le mettre lui même en haute dispo… ce qui nous ramène au point de départ, sans mentionner que vous n'avez pas vraiment de moyen pour que les deux pgpool que vous allez mettre en haute dispo soient d'accord sur l'état du cluster), il consomme pas mal de ressources… et le code n'a vraiment rien de rassurant.

Il y a peut-être des choses qui ont progressé sur pgpool, mais j'ai eu tellement de problèmes avec que je ne suis pas retourné voir depuis 2 ou 3 ans…

---

Marc.

yohmartin

Membre

Re : Outils de failover automatique

Pour partager lon expérience, il existe maintenant une extension watchdog qui gère la vip et discute avec l'autre serveur pgpool.
Pgpool peux donc etre installé sur les 2 serveurs postgres, ce qui enlève le spof.
Effectivement au niveau pooling il semble moins bon que pgbouncer, mais moi je l'utilise que pour la partie VIP + bascule automatique.
pgpool verifie l'etat de la base de données et de pgpool, si l'un des deux tombe, il bascule sur l'autre serveur.
Il faut créer un shell qui permet de faire le promote automatique mais c'est pas tres compliqué.
Dans mes tests, le plus dérangeant est le failback.
Personnellement, j'ai testé les 3 solutions : PAF, repmgr et Pgpool.
je trouve PAF assez complexe a mettre en place mais intéressant une fois bien parametré.
repmgr est la solution qui me plais le plus mais je n'ai pas trouvé de facon de gérer une vip.
Du coup, pgpool est plus simple que PAF a mettre en place et gere des vip assez facilement.
Jusqu’à présent je n'ai eu aucun souci avec.
Je n'ai pas encore constaté d'overhead mais pour l'instant la base n'est pas trop sollicitée.

Dernière modification par yohmartin (11/10/2016 14:34:53)

ioguix

Administrateur

Re : Outils de failover automatique

Bonjour,

Comme l'écrivait Marc, la bascule auto est complexe à mettre en œuvre, d'autant plus pour un SGBD si on ne veut pas se retrouver dans une situation de split brain.

Le fait est que Pacemaker est une référence incontournable et qu'aucun autre projet sous Linux ne lui arrive à la cheville en terme de fonctionnalité. C'est exactement pour cette raison que PAF a été conçu comme une simple brique (ressource agent) de ce projet essentiel.

Pour rappel, jusqu'à présent, le fencing est la SEULE solution propre pour éviter les split brain, d'autant plus sur un cluster à deux nœud. Je ne vois aucune méthode de fencing dans repmgr ou dans pgpool. Ces deux projets laissent ce "détail" à la discrétion des administrateurs s'ils y pensent à travers des scripts maison à exécuter...

À propos d'avoir une IP secondaire qui se promène là où le maître se situe, là aussi repmgr laisse les administrateurs se débrouiller...C'est faisable, mais ça nécessite un peu d'huile de coude et au moins 2 scripts distincts (pour la bascule à chaud et en cas de redémarrage du serveur)

Coté pgpool, c'est pas beaucoup mieux. Ils ont **encore** ré-écrit la roue en intégrant un watchdog dans leur code. Ce dernier n'est évidement pas parfait et complet et a déjà un sacré historique en terme de bug. Un client m'a rapporté avoir abandonné le watchdog de pgpool car ce dernier provoquait des incidents sur le réseau local à cause de son activité ARP. Un autre à mis pgpool en haute disponibilité grâce à ... Pacemaker pour éviter qu'il soit un SPoF (ce dernier l'utilisait comme répartiteur de charge).

Donc oui, Pacemaker est complexe à comprendre et mettre en œuvre pour le nouveau venu, mais il y a quelques raison derrière ça. Et l'intérêt ensuite, c'est qu'il fait tout, vraiment TOUT, et le fait bien: gestion des ressources, failover, switchover, dépendances des ressources entre elles, fencing, watchdog, quorum, règles, etc. PAF n'est qu'une simple brique au dessus qui exploite au mieux ce que nous offre ce beau projet.

++