Re: Standalone synchronous master

On Tue, Jan  3, 2012 at 09:22:22PM -0500, Robert Haas wrote:
> On Tue, Dec 27, 2011 at 6:39 AM, Alexander Björnhagen
> <alex.bjornhagen@gmail.com> wrote:
> > And so we get back to the three likelihoods in our two-node setup :
> >
> > 1.The master fails
> >  - Okay, promote the standby
> >
> > 2.The standby fails
> >  - Okay, the system still works but you no longer have data
> > redundancy. Deal with it.
> >
> > 3.Both fail, together or one after the other.
> 
> It seems to me that if you are happy with #2, you don't really need to
> enable sync rep in the first place.
> 
> At any rate, even without multiple component failures, this
> configuration makes it pretty easy to lose durability (which is the
> only point of having sync rep in the first place).  Suppose the NIC
> card on the master is the failing component.  If it happens to drop
> the TCP connection to the clients just before it drops the connection
> to the standby, the standby will have all the transactions, and you
> can fail over just fine.  If it happens to drop the TCP connection to
> the just before it drops the connection to the clients, the standby
> will not have all the transactions, and failover will lose some
> transactions - and presumably you enabled this feature in the first
> place precisely to prevent that sort of occurrence.
> 
> I do think that it might be useful to have this if there's a
> configurable timeout involved - that way, people could say, well, I'm
> OK with maybe losing transactions if the standby has been gone for X
> seconds.  But if the only possible behavior is equivalent to a
> zero-second timeout I don't think it's too useful.  It's basically
> just going to lead people to believe that their data is more secure
> than it really is, which IMHO is not helpful.

Added to TODO:
       Add a new "eager" synchronous mode that starts out synchronous but       reverts to asynchronous after a failure
timeoutperiod
 
           This would require some type of command to be executed to alert       administrators of this change.
       http://archives.postgresql.org/pgsql-hackers/2011-12/msg01224.php


--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +