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
Re: Issues with Quorum Commit |
Список | 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 по дате отправления: