Re: Standalone synchronous master - Mailing list pgsql-hackers

From Aidan Van Dyk
Subject Re: Standalone synchronous master
Date
Msg-id CAC_2qU91iUN6DMVa0=pL1SG7tacaK5Bw6UDW6sCWYN0f0BwYnw@mail.gmail.com
Whole thread Raw
In response to Re: Standalone synchronous master  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Standalone synchronous master  (Robert Haas <robertmhaas@gmail.com>)
Re: Standalone synchronous master  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
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.


pgsql-hackers by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Re: review: CHECK FUNCTION statement
Next
From: Peter Geoghegan
Date:
Subject: Re: BGWriter latch, power saving