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 stho...@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
