Re: Issues with Quorum Commit

On 07.10.2010 21:38, Markus Wanner wrote:
> 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.

There is a very good use case for that particular set up, actually. If
your hot standby is guaranteed to be up-to-date with any transaction
that has been committed in the master, you can use the standby
interchangeably with the master for read-only queries. Very useful for
load balancing. Imagine a web application that's mostly read-only, but a
user can modify his own personal details like name and address, for
example. Imagine that the user changes his street address and clicks
'save', causing an UPDATE, and the next query fetches that information
again to display to the user. If you use load balancing, the query can
be routed to the hot standby server, and if it lags even 1-2 seconds
behind it's quite possible that it will still return the old address.
The user will go "WTF, I just changed that!".

That's the "load balancing" use case, which is quite different from the
"zero data loss on server failure" use case that most people here seem
to be interested in.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com