Re: Failover para Streaming Replication

Gracias Gerardo..

Justamente cuando leía la WIKI de postgres me encontré con algo que
indicaba lo de repetir la operación de SR en estas situaciones... pero
quería asegurarme de tener una respuesta/experiencia actualizada al
respecto.

OK, con esto ya sé que manualmente puedo continuar la operación de la
plataforma en forma inmediata (con el archivo trigger_failover) y que una
vez que recupere el Nodo1 tendré que repetir la operación de realizar los
backups y habilitar nuevamente el SR (algo que no es tan pesado
considerando la plataforma asociada.... y tampoco se caerá fácilmente....
lleva 3 años funcionando sin caídas y sólo estábamos respaldando y siempre
dejábamos pendiente esto de la replicación directa...)

De todas formas dejo la consulta abierta para quienes me puedan compartir
su experiencia con este método... o sí han probado otras alternativas sin
uso de herramientas externas... (estoy con pg 9.2)..

Gracias nuevamente..

En otro hilo haré otras consultas respecto a la dinámica del SR... ojala
puedan aclararme las dudas..

Slds.
AP.

El 11 de mayo de 2016, 23:47, Gerardo Herzig <gherzig(at)fmed(dot)uba(dot)ar> escribió:

> >
> > Buenas Tardes Estimad(at)s
> >
> >
> > Necesito orientación para habilitar failover en el tema streaming
> > replicación.... sin WAL..
> >
> >
> > Escenario:
> >
> >
> > Un Master (192.168.10.1) (ref nodo1)
> > Un Esclavo (192.168.10.2) (ref nodo2)
> >
> > Esclavo : recovery.conf
> >
> >
> >
> > standby_mode = 'on'
> > primary_conninfo = 'host=192.168.10.1 port=5432 user=rep'
> > trigger_file = '/mi_path_data/pg_failover_trigger'
> >
> >
> >
> >
> -------------------------------------------------------------------------------------------
> >
> >
> > (*) ..Tengo la duda de si en el Master deba habilitarse este
> > parámetro pero tomé la conf de un ejemplo de alguien que tenía
> > iguales el postgres.conf en maestro y esclavo y le
> > funcionaba.......... y en mi caso también funcionó.. (o talvez no
> > tuvo ningún efecto en el buen funcionamiento).....
> >
> >
> > La configuración anterior me permitió hacer pruebas que fueron
> > exitosas en cuanto a lo que replicación se refiere... quedando el
> > master para las transacciones.. y el esclavo como lectura.
> > Sin embargo, ahora necesito planificar un failover (manual)... sin
> > usar pgpool o repmngr o pgHA.. o herramientas similares. Googleando
> > me encontré con una solución que indicaba que ante una caída del
> > Master simplemente había que crear en el esclavo el archivo
> > pg_failover_trigger especificado en el recovery.conf del
> > esclavo..... Al hacer esto el esclavo dejaba de ser esclavo y se
> > transformaba en Maestro......
>
> Hasta ahi es cierto. Crear ese archivo en la replica desliga al slave del
> master, o sea lo convierte en "master", pero ya no guarda ninguna relacion
> con el "otro master". Ambas instancias de postgres comenzaron a diverger
> una de otra, y ya no puedes "retomar" la condicion de "master - slave", a
> menos que hagas todo de nuevo.
>
> De manera nativa, streaming replication no tiene ningun mecanismo de
> failover ni switch-over.
> Entonces, suponiendo un failover (o un switch-over planificado), podrian
> pensarse los siguientes pasos:
>
> 1) Bajas (o se pierde) el nodo1
> 2) "toucheas" el archivo trigger_failover en nodo2, o su comando
> equivalente "pg_ctl promote" (tambien en nodo2)
> 3) Cambias la ip del nodo1, o haces los ajustes necesarios en tus DNS
> 4) Te aseguras que el nodo1 no vuelva a levantar, o le cambias la IP.
>
> Cuando el nodo1 vuelva a estar operativo....pues tendras que recrear
> streaming replication nuevamente, con tu nodo2 apuntando su replica al
> nodo1. Esto te dejara la cosa lista para hacer un "switch back", o sea
> poner operativo tu nodo1 nuevamente como master.
>
> HTH
> Gerardo
>