Re: Synchronous Standalone Master Redoux

Поиск
Список
Период
Сортировка
От Shaun Thomas
Тема Re: Synchronous Standalone Master Redoux
Дата
Msg-id 4FFC3CD6.8050607@optionshouse.com
обсуждение исходный текст
Ответ на Re: Synchronous Standalone Master Redoux  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Synchronous Standalone Master Redoux  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Synchronous Standalone Master Redoux  (Josh Berkus <josh@agliodbs.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: expression evaluation with expected datatypes
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: expression evaluation with expected datatypes