Re: Failover para PostgreSQL

On 01/10/14 22:27, marcelo mendoza wrote:
> Buenas tardes, cual sería una forma de colocar un pgbouncer en alta
> disponibilidad? o sea dos nodos pgbouncer que se conecten a un
> Postgres que se está replicando por medio de un repmgr? ya que si
> pongo sólo un pgbouncer sería un unico punto de falla, como podría
> configurar las IP de modo a que los dos pgbouncer balanceen las
> conexiones para mi Postgres?
>
> Saludos

Hola, Marcelo. No sé si estás preguntando sólo por HA o también por
balanceo de carga. Para lo primero, como te han comentado en el thread,
pgbouncer no está preparado. Necesitarás tener un pgbouncer en cada nodo
de aplicación (lo que suele funcionar bien), y que todos se conecten a
las bases de datos. Pero esta arquitectura no está exenta de problemas:

- Puede requerir un alto número final (agregado de todos los
app+pgbouncer) de conexiones a la base de datos, lo que puede degradar
mucho su rendimiento.
- El diseño de max_connections es difícil (porque el número de
app+pgbouncer pueden crecer "elásticamente")
- No tiene balanceo de carga
- Es complejo que cada pgbouncer debe configurar conexiones a todas las
bases de datos del cluster (maesto y esclavos)

Alternativamente, puedes meter haproxy en la ecuación, que te da
balanceo de carga y te va a permitir reducir el número global de
conexiones. Puedes tener por ejemplo app+pgbouncer y dichos pgbouncer
conectan a haproxy, que balancea la carga. Esto sólo aplica a esclavos,
obviamente, pues sólo hay un maestro. Pero me imagino esto ya lo tienes
resuelto a nivel de app (distingues entre rw y ro). Es fundamental en
este caso que en la gestión de la promoción de un esclavo a maestro por
la caída de éste, se actualice la configuración de haproxy (basta con un
reload). Pan comido (ironía).

Suerte y saludos,

Álvaro

>
> El 25 de septiembre de 2014, 20:57, Álvaro Hernández Tortosa
> <aht(at)8kdata(dot)com <mailto:aht(at)8kdata(dot)com>> escribió:
>
>
> On 24/09/14 05:02, Alvaro Herrera wrote:
>
> Jaime Casanova escribió:
>
> 2014-09-23 9:00 GMT-05:00 marcelo mendoza
> <jmarcelo(dot)mendoza(at)gmail(dot)com
> <mailto:jmarcelo(dot)mendoza(at)gmail(dot)com>>:
>
> Muchas gracias por su respuesta, estoy leyendo que el
> repmgr tiene failover
> automático también, alguien ya lo probó? En
> comparación con pgpool cual
> proyecto es mas estable?
>
> Empieza por eliminar de tu cabeza la idea de usar RHCS, al
> menos si no
> quieres tener dolores de cabeza. RHCS no usa replicación sino
> almacenamiento compartido lo que significa que si tu
> storage falla te
> fregaste.
>
> Jaime está siendo amable. RHCS no sólo "te fregaste si el storage
> falla"; en algunos clientes (sí, más de uno) hemos visto que
> el RHCS
> activamente corrompe datos. Yo no conozco la tecnología pero la
> evidencia incontestablemente indica que el cluster por alguna
> razón en
> ciertas circunstancias levanta los dos servidores
> simultáneamente, lo
> cual corrompe los datos en muy poco tiempo.
>
>
> Por si sirve de algo, nosotros hemos realizado una instalación
> hace unos meses de un cluster activo-pasivo con RHCS (petición
> expresa del cliente) y la verdad ha funcionado a las mil
> maravillas. Hemos realizado pruebas muy agresivas de failover y
> failback sin el menor de los problemas. Lleva en producción desde
> entonces. Es bien cierto que es costoso montarlo bien, y que
> dependiendo de qué tecnología de disco compartido puede tener más
> riesgos. En el caso que montamos, se usaba iSCSI con multipath y
> esta propia tecnología ya impide (independientemente de RHCS) que
> se use el disco por dos máquinas simultáneamente, por lo que no
> debería haber corrupción de datos.
>
> Obviamente, es una solución con ventajas:
>
> - El failover es rapidísimo (pocos segundos)
> - Nunca hay pérdida de datos (por que se caiga el maestro)
> - Es transparente para los clientes (los servidores tienen una IP
> virtual y el cliente no se entera del cambio, salvo las conexiones
> abiertas, claro, pero esto es inevitable siempre)
>
> e inconvenientes:
>
> - Sólo dos nodos, sólo uno activo
> - Más complejo y más partes móviles
> - Traslada el SPOF al almacenamiento, si bien lograr
> almacenamiento suficientemente redundado (a nivel de hw) no es
> complejo, sino algo muy habitual a día de hoy
>
> En todo caso, no entiendo la combinación de RHCS con pgpool.
> Si alguien monitoriza es, precisamente, RHCS y no pgpool.
>
> Espero que sirva la información. Saludos,
>
> Álvaro
>
>
>
> --
> Álvaro Hernández Tortosa
>
>
> -----------
> 8Kdata
>
>
> -
> Enviado a la lista de correo pgsql-es-ayuda
> (pgsql-es-ayuda(at)postgresql(dot)org <mailto:pgsql-es-ayuda(at)postgresql(dot)org>)
> Para cambiar tu suscripción:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>
>
>
>
> --
> Marcelo Mendoza
> (0983) 383-752

--
Álvaro Hernández Tortosa

-----------
8Kdata