Re: Issues with Quorum Commit

On Thu, Oct 7, 2010 at 2:10 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
>
>> To get "non-stale" responses, you can only query those k=3
>> servers.  But you've shot your self in the foot because you don't
>> know which 3/10 those will be.  The other 7 *are* stale (by
>> definition). They talk about picking the "caught up" slave when
>> the master fails, but you actually need to do that for *every
>> query*.
>
> With web applications, at least, you often don't care that the data
> read is absolutely up-to-date, as long as the point in time doesn't
> jump around from one request to the next.  When we have used load
> balancing between multiple database servers (which has actually
> become unnecessary for us lately because PostgreSQL has gotten so
> darned fast!), we have established affinity between a session and
> one of the database servers, so that if they became slightly out of
> sync, data would not pop in and out of existence arbitrarily.  I
> think a reasonable person could combine this technique with a "3 of
> 10" synchronous replication quorum to get both safe persistence of
> data and reasonable performance.
>
> I can also envision use cases where this would not be desirable.

Well, keep in mind all updates have to be done on the single master.
That works pretty well for fine-grained replication, but I don't think
it's very good for full-cluster replication.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company