Vous souhaitez améliorer la disponibilité de votre base Postgresql ? Demandez à PGPool-II de s'en occuper !

Un peu d'histoire ...

A l'origine du projet (début des années 2000), Tatsuo Ishii principal développeur de la solution souhaitait créer un simple logiciel de gestion de pool de connexion pour Postgresql. Il l'appela donc PGPool.
Après plusieurs versions et diverses fonctions ajoutées, il a décidé en 2006 de renommer le projet en PGPool-II, nom qu'il porte toujours aujourd'hui.

Pour quoi faire ?

PGPool-II est un middleware qui se place entre les applications et les instances Postgresql. Il a diverses fonctions dont celles de gérer des pools de connexion applicatives, la répartition de charge (lectures sur le slave), et la gestion du failover des Postgresql. Le service PGPool-II peut lui-même être mis en haute disponibilité grâce à un système de watchdog (principalement développé par Muhammad Usama, core dev de PGPool-II sur la partie haute disponibilité du service).
Nous allons voir dans cet article les principes de base du fonctionnement de PGPool-II en ce qui concerne la haute disponibilité du service et la gestion du failover Postgresql.

Architecture :
Voici le schéma de l'architecture type que l'on met en place chez Claranet :

pgpool_0.png

Nous avons deux serveurs sur lesquels sont installés PGPool-II et Postgresql.
Nous avons une réplication de type streaming (réplication native Postgresql) entre le serveur 1 (qui a l'instance Postgresql primaire) et le serveur 2 (qui a l'instance Postgresql standby).
PGPool est configuré en HA, il y a une notion de Master/Slave sur le service, et le premier qui démarre devient Master et monte la VIP (IP virtuelle qui peut être monté sur l'un ou l'autre des serveurs). Le Slave restera à l'écoute du Master et reprendra la VIP en cas de perte du Master.

La haute disponibilité du service PGPool-II

Là je tire mon chapeau à Muhammad Usama ! L'idée d'utiliser une liste de serveurs témoin (qui n'ont besoin de rien d'autre que savoir répondre au ping), est peut-être simple mais diablement efficace !
Les deux services PGPool-II (celui du serveur 1 et celui du serveur 2) échanges des trames heartbeat entre eux. Lorsqu'ils n'arrivent plus à se joindre, ils vont chacun tenter de « pinguer » la liste de serveurs témoin (nous utilisons généralement la liste des serveurs applicatifs, AppSrv1 à 3 sur le schéma). Si aucun de ces serveurs témoin n'est joignable le service PGPool-II va considérer qu'il est isolé du réseau. S'il était Master, il va démonter sa VIP et stopper son service. Si le slave peut joindre les serveurs témoin mais pas le Master PGPool-II, il va se promouvoir Master et monter la VIP. Je vous l'avais dit, simple mais efficace :)

Le failover des Postgresqls

Le Master PGPool-II va en permanence vérifier la disponibilité des Postgresql primaire et standby. Si on perd le Postgresql standby, PGPool-II note qu'il n'est plus disponible mais le service continu d'être assuré par le primaire. SI on perd le Postgresql primaire, PGPool-II note qu'il n'est plus disponible, promeut le standby en primaire(via un script à mettre en place) et redirige toute les requêtes vers ce nouveau primaire. Suite à cela il faudra reconstruire l'ex-primaire en standby et le réintégrer dans PGPool-II. Il recevra alors les requêtes de lecture (car load-balancing des lectures par PGPool-II).

Le tuning de PGPool-II, pas si simple

PGPool-II comporte énormément de paramètres, ce qui permet d'avoir une configuration aux petits oignons. Le revers de la médaille c'est qu'il n'est parfois pas évident de trouver la cause de comportement différents entre des serveurs physiques et des virtuels par exemple.

Conclusion

Si vous utilisez Postgresql (avec réplication) mais ne connaissez pas PGPool-II, je vous conseille fortement de vous y intéresser. Ce middleware a beaucoup de cordes à son arc, mais sa gestion de la haute disponibilité des instances Postgresql est celle qui m'a séduit le plus et je trouve que ce serait dommage de s'en priver.

Ecrit par christophe LE ROUX - Architecte DBA chez Claranet France

10 ans d'expérience sur les technologies Oracle (RAC, Dataguard, multi-tenant, ...) Postgresql (Hot Standby, PGPool,..) ou encore MySQL (réplication, clusters,..), je m'intéresse particulièrement aux architectures haute disponibilité mono ou multi-sites. Mes hobbies tournent autour de l'électronique et la programmation de microcontrôleur.
Linkedin

Contactez-nous

Contactez-nous

Nous construisons des solutions sur mesure pour nos clients.
Les informations recueillies à partir de ce formulaire font l’objet d’un traitement informatique destiné à la société Claranet afin de nous permettre de traiter la demande pour laquelle vous nous sollicitez. Les destinataires des données sont les services marketing et commerciaux du groupe Claranet. Conformément à la loi « informatique et libertés » du 6 janvier 1978 modifiée, vous disposez d’un droit d’accès et de rectification aux informations qui vous concernent. Veuillez-vous rapportez à la section des mentions légales de notre site internet pour de plus amples informations sur les modalités d’exercice de ces droits. Vous pouvez également, pour des motifs légitimes, vous opposer au traitement des données vous concernant.
3 + 0 =
Trouvez la solution de ce problème mathématique simple et saisissez le résultat. Par exemple, pour 1 + 3, saisissez 4.

Pour contacter un commercial

N'hésitez pas à nous appeler au 0826 007 656

Besoin de contacter le support technique ?
Nos équipes sont disponibles en 24x7x365.

Support Virtual Data Centre au 0826 007 653 (Numéro indigo)
Support Infogérance applicative au 0810 278 385 (Numéro indigo)
Support Colocation au 0826 007 653 (Numéro indigo)
Support Cloud Public en envoyant un mail à support