On Tue, 16 Jun 2020 at 14:56, amul sul <sula...@gmail.com> wrote:
> The high-level goal is to make the availability/scale-out situation > better. The feature > will help HA setup where the master server needs to stop accepting WAL > writes > immediately and kick out any transaction expecting WAL writes at the end, > in case > of network down on master or replication connections failures. > > For example, this feature allows for a controlled switchover without > needing to shut > down the master. You can instead make the master read-only, wait until the > standby > catches up, and then promote the standby. The master remains available for > read > queries throughout, and also for WAL streaming, but without the > possibility of any > new write transactions. After switchover is complete, the master can be > shut down > and brought back up as a standby without needing to use pg_rewind. > (Eventually, it > would be nice to be able to make the read-only master into a standby > without having > to restart it, but that is a problem for another patch.) > > This might also help in failover scenarios. For example, if you detect > that the master > has lost network connectivity to the standby, you might make it read-only > after 30 s, > and promote the standby after 60 s, so that you never have two writable > masters at > the same time. In this case, there's still some split-brain, but it's > still better than what > we have now. > > If there are open transactions that have acquired an XID, the sessions are > killed > before the barrier is absorbed. > > inbuilt graceful failover for PostgreSQL > That doesn't appear to be very graceful. Perhaps objections could be assuaged by having a smoother transition and perhaps not even a full barrier, initially. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> Mission Critical Databases
