Re: Synchronous Standalone Master Redoux

From: Shaun Thomas <sthomas(at)optionshouse(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Synchronous Standalone Master Redoux
Date: 2012-07-10 14:31:50
Message-ID: 4FFC3CD6.8050607@optionshouse.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)optionshouse(dot)com

______________________________________________

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2012-07-10 14:35:32 Re: expression evaluation with expected datatypes
Previous Message Tom Lane 2012-07-10 14:31:49 Re: expression evaluation with expected datatypes