> > Buenas Tardes Estimad@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 - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
