Hola a todos,
Me preguntaba si alguno de ustedes tiene experiencia con pgpool II en lugar de pgbouncer al usar Discourse y, de ser así, ¿cuál ha sido su impresión hasta ahora?
¿Lo han considerado, equipo, en algún momento y, de ser así, por qué?
Gracias,
Ismael
pgpool II no ofrece agrupación de transacciones. Sin ella, su valor en entornos de alojamiento a gran escala es extremadamente limitado y solo añadiría complejidad.
En una instalación estándar de Discourse “autohospedada”, tendrías dificultades para alcanzar entre 30 y 60 conexiones activas, y PostgreSQL no tendría problemas con esa cantidad. No es necesario incluir un agrupador de conexiones que complique tu configuración.
Muchas gracias, Sam. Efectivamente, como has dicho, para un número reducido de conexiones podría no tener sentido. Además, si tenemos en cuenta el agrupamiento de transacciones, en este caso solo hay un ganador.
Sin embargo, por lo que sé, he visto que pgbouncer no ofrece alta disponibilidad (HA), mientras que pgpool II sí. ¿Qué tal si colocamos un pgbouncer “delante” de un pgpool para permitir dicha función? ¿Cuál es la recomendación para un enfoque de HA que se adapte bien a Discourse?
Discourse ofrece HA de forma nativa mediante configuración global.
Ver: GitHub - discourse/rails_failover · GitHub
Y explora la configuración global aquí: discourse/config/discourse_defaults.conf at main · discourse/discourse · GitHub
Configurarías 2 pgbouncers en un modo de alta disponibilidad o con una cantidad enorme de conexiones requeridas.