Re: Issues with Quorum Commit

Поиск
Список
Период
Сортировка
От Markus Wanner
Тема Re: Issues with Quorum Commit
Дата
Msg-id 4CAE1399.6090106@bluegap.ch
обсуждение исходный текст
Ответ на Re: Issues with Quorum Commit  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: Issues with Quorum Commit  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: Issues with Quorum Commit  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
On 10/07/2010 03:19 PM, Dimitri Fontaine wrote:
> I think you're all into durability, and that's good. The extra cost is
> service downtime

It's just *reduced* availability. That doesn't necessarily mean
downtime, if you combine cleverly with async replication.

> if that's not what you're after: there's also
> availability and load balancing read queries on a system with no lag (no
> stale data servicing) when all is working right.

All I'm saying is that those use cases are much better served with async
replication. Maybe together with something that warns and takes action
in case the standby's lag gets too big.

Or what kind of customers do you think really need a no-lag solution for
read-only queries? In the LAN case, the lag of async rep is negligible
and in the WAN case the latencies of sync rep are prohibitive.

> My proposal is to make the risk window obvious and the
> behavior when you enter it configurable.

I don't buy that. The risk calculation gets a lot simpler and obvious
with strict guarantees.

Regards

Markus Wanner


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: standby registration (was: is sync rep stalled?)
Следующее
От: Markus Wanner
Дата:
Сообщение: Re: Issues with Quorum Commit