Thanks Scot.
But moving VIP is not feasible option for me.
At present PostgreSQL doesn't support for reloading of recovery.conf parameters via SIGHUP. To prevent recovery.conf reload for master IP, I can manage internal DNS to always point to the current master. However there are some cases where old master will come up as standby before the new master is elected. In this case it will lead to cascading replication.
So to overcome such cases reboot is a required. It can be achieved by restarting the wal receiver process too. But there is no straight forward way of restarting wal receiver process. The only way i figured out is to kill the wal receiver process. Postmaster will take care of restarting the wal receiver process. But here my worry is, will there be any side effect if i kill wal receiver process (even using TERM signal)?
Warm Regards,
"There is no Elevator to Success. You have to take the Stairs"
Point it at a VIP that travels with the master.
Scot Kreienkamp |Senior Systems Engineer | La-Z-Boy Corporate
One La-Z-Boy Drive| Monroe, Michigan 48162 | Office: 734-384-6403 | | Mobile: 7349151444 | Email: Scot.Kreienkamp@la-z-boy.com
Whenever there is a change in master, PostgreSQL service on standby nodes must be restarted (after changing the master IP in the recovery.conf) to ensure it is syncing with the new master.
Is there a way to point to new master without reboot of PostgreSQL on the standby?
"There is no Elevator to Success. You have to take the Stairs"
This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.