Re: Failover para PostgreSQL

Que tal Alvaro, mi idea es la siguiente
[image: Imágenes integradas 1]

Agregando el repmgr para hacer el failover de las réplicas de Master.

Está correcto esto?

Saludos

El 3 de octubre de 2014, 5:44, Álvaro Hernández Tortosa <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> 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>:
>>>>
>>>>> 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)
>> 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