Bonjour à tous,
Je me demandais si l’un d’entre vous a de l’expérience avec pgpool II à la place de pgbouncer en utilisant Discourse, et si oui, quel est votre ressenti jusqu’à présent ?
Est-ce que vous, l’équipe, envisagez cela à un moment donné et, si oui, pourquoi ?
Merci,
Ismael
pgpool II ne prend pas en charge le regroupement des transactions. Sans cette fonctionnalité, son utilité est extrêmement limitée dans les hébergements à grande échelle et il ne ferait qu’ajouter de la complexité.
Sur une instance Discourse « auto-hébergée » standard, vous auriez du mal à atteindre 30 à 60 connexions actives, et PostgreSQL ne rencontrera aucun problème avec un tel volume. Il n’est donc pas nécessaire d’ajouter un pooler de connexions pour compliquer votre configuration.
Un grand merci, Sam. En effet, comme tu l’as dit, pour un nombre limité de connexions, cela peut ne pas avoir de sens. De plus, en tenant compte du pooling des transactions, il n’y a qu’un seul gagnant dans ce cas.
Cependant, à ma connaissance, j’ai constaté que pgbouncer ne propose pas de haute disponibilité (HA), tandis que pgpool II le fait. Qu’en est-il de placer pgbouncer « devant » pgpool pour permettre cette fonctionnalité ? Quelle est la recommandation pour une approche HA qui convienne bien à Discourse ?
Discourse propose la haute disponibilité (HA) dès la sortie de la boîte grâce à une configuration globale.
Voir : GitHub - discourse/rails_failover · GitHub
Et explorez les paramètres globaux ici : discourse/config/discourse_defaults.conf at main · discourse/discourse · GitHub
Vous configurerez deux pgbouncers dans un mode haute disponibilité ou nécessitant un nombre énorme de connexions.