Aidan Van Dyk <aidan@highrise.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.
-Kevin
