Re: Failover para PostgreSQL

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

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