Re: Synchronous Standalone Master Redoux - Mailing list pgsql-hackers

From Shaun Thomas
Subject Re: Synchronous Standalone Master Redoux
Date
Msg-id 4FFC3CD6.8050607@optionshouse.com
Whole thread Raw
In response to Re: Synchronous Standalone Master Redoux  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Synchronous Standalone Master Redoux
Re: Synchronous Standalone Master Redoux
List pgsql-hackers
On 07/09/2012 05:15 PM, Josh Berkus wrote:


> "Total-consistency" replication is what I think you want, that is, to
> guarantee that at any given time a read query on the master will return
> the same results as a read query on the standby.  Heck, *most* people
> would like to have that.  You would also be advancing database science
> in general if you could come up with a way to implement it.

Doesn't having consistent transactional state across the systems imply that?

> So I'm unclear on why sync rep would be faster than async rep given
> that they use exactly the same mechanism.  Explain?

Too many mental gymnastics. I get that async is "faster" than sync, but 
the inconsistent transactional state makes it *look* slower. If a 
customer makes an order, but just happens to check that order state on 
the secondary before it can catch up, that's a net loss. Like I said, 
that's fine for our DR system, or a reporting mirror, or any one of 
several use-case scenarios, but it's not good enough for a failover when 
better alternatives exist. In this case, better alternatives are 
anything that can guarantee transaction durability: DRBD / PG sync.

PG sync mode does what I want in that regard, it just has no graceful 
failure state without relatively invasive intervention. Theoretically we 
could write a Pacemaker agent, or some other simple harness, that just 
monitors both servers and performs an LSB HUP after modifying the 
primary node to disable synchronous_standby_names if the secondary dies, 
or promotes the secondary if the primary dies. But after being spoiled 
by DRBD knowing the instant the secondary disconnects, but still being 
available until the secondary is restored, we can't justifiably switch 
to something that will have the primary hang for ten seconds between 
monitor checks and service reloads.

I'm just saying I considered it briefly during testing the last few 
days, but there's no way I can make a business case for it. PG sync rep 
is a great step forward, but it's not for us. Yet.

-- 
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
sthomas@optionshouse.com



______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: expression evaluation with expected datatypes
Next
From: Pavel Stehule
Date:
Subject: Re: expression evaluation with expected datatypes