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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
