Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
J'utilise Postgres 8.4 en production dans mon entreprise et il est prévu de migrer sur Postgres 9 dans les mois qui viennent. Je suis actuellement en train de me renseigner sur l'état de l'art en matière de clustering autour d'une base Postgres 9 car nous aimerions disposer d'un failover.
Pour le moment je me suis intéressé à repmgr (http://projects.2ndquadrant.com/repmgr) et j'aimerais savoir si vous aviez eu des retours d'expérience ou des avis sur des outils de clustering autour de Postgres 9.
Bien cordialement,
Miguel Santiago
Hors ligne
repmgr est un outil intéressant. Cela étant dit, il n'est pas nécessaire pour mettre en place de la réplication et la maintenir.
Guillaume.
Hors ligne
J'allais oublier que ce qu'apporte repmgr est en majorité ajouté à PostgreSQL 9.1. Certaines parties n'ont pas été reprises mais la majorité l'a été.
Guillaume.
Hors ligne
Merci de votre réponse rapide!
Postgres 9 est suffisant pour maintenir la réplication, mais nous sommes également intéressés par une fonctionnalité de failover - si possible automatique - pour effectuer un switch en cas de problème sur le maitre.
Pensez-vous que cette fonctionnalité sera aussi proposée dans Postgres 9.1 ?
Hors ligne
PostgreSQL 9.1 est déjà sortie. Le failover est implémenté depuis la version 9.0. Le failover automatique n'est pas proposé et ne le sera certainement jamais. Beaucoup s'opposent à ce genre d'ajout considéré comme dangereux. Cela étant dit, il est simple d'ajouter ça avec un Heartbeat.
Guillaume.
Hors ligne
Merci beaucoup pour vos éclaircissements.
Bonne soirée à vous!
Miguel
Hors ligne
Merci beaucoup pour vos éclaircissements.
Bonne soirée à vous!Miguel
notez que repmgr permet de trouver le meilleur node pour une bascule de failover (c'est à dire trouver le serveur qui a le moins de 'lag' avec le master) et que c'est grandement utile pour fiabiliser les bascules, d'autant plus en mode automatique.
http://repmgr.org/
Vous pouvez aussi voir les slides de repmgr lors du CHAR(11) (la conférence spécialisée dans le Clustering, Haute-Dispo, et Réplication)
http://www.2ndquadrant.com/static/2quad … char11.pdf
Depuis, pgbouncer a évolué et permet de mettre en place une architecture très simple à administrer à l'aide de serveurs DNS. (et rend obselete les serveurs type LVS)
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
Hors ligne
Houla, doucement quand même pour enterrer LVS 
Il fait plein de choses qui sont impossibles avec un DNS… comme rediriger vers le serveur le moins chargé… le DNS se contente d'un round robin (enfin le DNS quand on se contente de le faire avec un DNS, et pgbouncer aussi se contente d'un round robin pour le moment).
Dans LVS, on peut détecter la charge d'un serveur (par sa charge CPU par exemple, ou simplement par le nombre de sessions connectées) et rediriger vers le serveur le moins chargé. On peut aussi faire de la réplication de sessions entre 2 serveurs LVS, afin que la bascule de l'un vers l'autre soit transparente (pas de perte de session TCP).
Et oui, tout ça marche, j'en ai eu en prod pendant des années (dans un contexte où la perte de session n'était pas envisageable)
Ça n'enlève rien au mérite de pgbouncer, qui sait multiplexer des sessions Postgres, ce qui n'est évidemment pas fait par LVS. Mais LVS fait des choses qui ne sont pas accessibles à pgbouncer (parce qu'au niveau kernel).
Par contre, tout à fait d'accord avec toi, l'archi pgbouncer + dns round robin, c'est très simple à mettre en place et à administrer.
Marc.
Hors ligne
Pages : 1
