Re: Failover para PostgreSQL

From: Álvaro Hernández Tortosa <aht(at)8Kdata(dot)com>
To: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Failover para PostgreSQL
Date: 2014-09-26 00:57:45
Message-ID: 5424BA09.2070904@8Kdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda


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

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Eduardo Morras 2014-09-27 08:43:42 Re: Preguntas sobre webminar BDR
Previous Message Hellmuth Vargas 2014-09-25 21:47:21 Re: Preguntas sobre webminar BDR