On Tue, Jan 3, 2012 at 9:22 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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.
So, I'm a big fan of syncrep guaranteeing it's guarantees. To me,
that's the whole point. Having it "fall out of sync rep" at any point
*automatically* seems to be exactly counter to the point of sync rep.
That said, I'm also a big fan of monitoring everything as well as I could...
I'ld love a "hook" script that was run if sync-rep state ever changed
(heck, I'ld even like it if it just choose a new sync standby).
Even better, is there a way we could start injecting "notify" events
into the cluster on these types of changes? Especially now that
notify events can take payloads, it means I don't have to keep
constantly polling the database to see if it things its connected,
etc.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.