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(dot)bjornhagen(at)gmail(dot)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 timeout period

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +