Re: Failover para PostgreSQL

On 03/10/14 15:14, marcelo mendoza wrote:
> Que tal Alvaro, mi idea es la siguiente
> Imágenes integradas 1
>
> Agregando el repmgr para hacer el failover de las réplicas de Master.
>
> Está correcto esto?

Yo la verdad creo que los pgbouncer tienen mucho mejor efecto
cuando están en la misma máquina que el app server, porque de lo
contrario no evitas el coste de establecimiento de conexión entre app
server y pgbouncer.

Saludos,

Álvaro

>
> Saludos
>
> El 3 de octubre de 2014, 5:44, Álvaro Hernández Tortosa
> <aht(at)8kdata(dot)com <mailto:aht(at)8kdata(dot)com>> escribió:
>
>
> 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
>
>
>
>
> --
> Marcelo Mendoza
> (0983) 383-752

--
Álvaro Hernández Tortosa

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