Alta disponibilidad / escalabilidad de PostgreSQL con HAProxy y PGBouncer

Tengo varios servidores PostgreSQL para una aplicación web. Por lo general, un maestro y varios esclavos en modo de espera activa (replicación de transmisión asíncrona).

Uso PGBouncer para la agrupación de conexiones: una instancia instalada en cada servidor PG (puerto 6432) que se conecta a la base de datos en localhost. Yo uso el modo de grupo de transacciones.

Para equilibrar la carga de mis conexiones de solo lectura en esclavos, uso HAProxy (v1.5) con una configuración más o menos así:

listen pgsql_pool 0.0.0.0:10001
        mode tcp
        option pgsql-check user ha
        balance roundrobin
        server master 10.0.0.1:6432 check backup
        server slave1 10.0.0.2:6432 check
        server slave2 10.0.0.3:6432 check
        server slave3 10.0.0.4:6432 check

Entonces, mi aplicación web se conecta a haproxy (puerto 10001), que conecta las conexiones de equilibrio en múltiples pgbouncer configurados en cada esclavo PG.

Aquí hay un gráfico de representación de mi arquitectura actual:

Esto funciona bastante bien así, pero me doy cuenta de que algunos implementan esto de manera bastante diferente: la aplicación web se conecta a una sola instancia de PGBouncer que se conecta a HAproxy que equilibra la carga en varios servidores PG:

¿Cuál es el mejor enfoque? ¿El primero (el actual) o el segundo? ¿Hay alguna ventaja de una solución sobre la otra?

Gracias

Su configuración actual de HAProxy -> PGBouncer -> PGServer Approch es mejor. Y eso solo funciona. Aquí está la razón: HAProxy redirige la conexión a diferentes servidores. esto resulta en un cambio de dirección MAC en la conexión de la base de datos. Entonces, si PGBouncer está por encima de HAProxy, cada vez que se invalidan las conexiones en el grupo debido al cambio de dirección MAC.

pgbouncer mantiene conexiones en un grupo con un servidor postgres. Los tiempos de establecimiento de la conexión TCP son significativos en un entorno de gran volumen.

Los clientes que realicen una gran cantidad de solicitudes DB deberán configurar una conexión con un PGBouncer remoto para cada solicitud. Esto es más costoso que ejecutar PgBouncer localmente (por lo que la aplicación se conecta a pgbouncer localmente) y pgBouncer mantiene un grupo de conexiones con el servidor PG remoto.

Entonces, IMO, PGBouncer -> HAProxy -> PGServer parece ser mejor que, HAProxy -> PGBouncer -> PGServer, especialmente cuando el PGBouncer es local para la aplicación del cliente.

Tengo que estar en desacuerdo con la respuesta proporcionada por donatello.

Verá, si su aplicación no administra las conexiones de base de datos utilizando un grupo local, creará una nueva conexión cada vez que necesite consultar la base de datos; eso sucede exactamente igual cuando usa PgBouncer, por lo que tendrá una muy buena mejora al usarlo.

Cuando PgBouncer administra las conexiones de PostgreSQL al agruparlas, el tiempo que su aplicación pasa abriendo una conexión disminuye significativamente, en comparación con cuando la conexión se abre directamente a DB. Esto se debe a que PG es bastante lento para verificar y verificar las credenciales y todo cada vez que se solicita una conexión.

Entonces, la aplicación de enfoque -> HAProxy -> [PgBouncer -> PostgreSQL] es la mejor, porque PgBouncer ahorra el tiempo de conexión a PG. También es importante tener en cuenta el modo de agrupación. Debes ser consciente del comportamiento de tu aplicación. ¿Es mayormente transaccional? ¿O es más bien ejecutar un montón de pequeñas oraciones SQL con una alta concurrencia? Todos esos parámetros tienen un efecto en el rendimiento.