Why is it not feasible? How do your DB clients know to switch to the new master? I’m using pcs clustering in my environment to manage two production nodes, automatic failover, and two VIPs (one for master, one for slave). All my clients point at either the master VIP or the slave VIP. When we have a role change where the master is moved we do nothing to any clients or replication slaves, they automatically reconnect in all cases after the pcs cluster activates the two VIPs. Also in case the primary slave would go down pcs will move the primary slave VIP to the master so that replication continues. Makes maintenance easy, I can reboot the primary slave at any time and everything just continues working. There is easy to use open source software that will do nothing but VIPs. I used to use keepalived for that purpose. You define a script that will let it determine which node to activate the VIP on. In the script have it check which node is the master, and it will activate that VIP on the master. When you transition the master to another server the VIP will travel with the master. Scot Kreienkamp |Senior Systems Engineer | La-Z-Boy Corporate From: Madan Kumar [mailto:madankumar1993@xxxxxxxxx]
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)? On Tue, Oct 30, 2018 at 6:27 PM Scot Kreienkamp <Scot.Kreienkamp@xxxxxxxxxxxx> wrote:
|