incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philip O'Toole <phi...@loggly.com>
Subject Re: QUORUM writes, QUORUM reads -- and eventual consistency
Date Sat, 25 Aug 2012 06:27:04 GMT
Hi Derek -- thanks. More inline.

On Fri, Aug 24, 2012 at 11:52:49PM -0600, Derek Williams wrote:
> On Fri, Aug 24, 2012 at 10:55 PM, Philip O'Toole <philip@loggly.com> wrote:
> 
> > But consider this. Say I have a replication factor of 3. I request a
> > QUORUM write, and it fails because the write only reaches 1 node. Perhaps
> > there is a temporary partition in my cluster. Now, asynchronously, a
> > different reader performs a QUORUM read of the same cluster and just before
> > it issues the read, the partition is resolved. The quorum read is satisfied
> > by the two nodes that have *not* received the latest write (yet). Doesn't
> > this mean that the read does not "reflect the most recent write"? I realise
> > this is very unlikely to happen in practise, but I want to be sure I
> > understand all this.
> >
> 
> Others might disagree, but as long as the view from the second reader
> remains consistent then I see no problem. If it were to have read the newer
> data from the 1 node and then afterwards read the old data from the other 2
> then there is a consistency problem, but in the example you give the second
> reader seems to still have a consistent view. Trying to guarantee that all
> clients will have the same view at all times is working against Cassandra's
> strengths.

I can agree with this interpretation, and that it is a reasonable interpretation of "consistency".

> 
> Where quorum reads and writes are most important is when consistency is
> required from the point of view of a single client.

A single client is exactly what I am thinking about.

> 
> This is besides the point that the documentation states that the sum of the
> nodes written to and read from needs to be greater then the replication
> factor for the statement to be true. In your example only 1 node was
> written to, when 2 were required to guarantee consistency. The intent to do
> a quorum write is not the same as actually doing one.

I *think* we're saying the same thing here. The addition of the word "successful" (or something
more suitable) would make the documentation more precise, not less.

> 
> -- 
> Derek Williams

-- 
Philip O'Toole
Senior Developer
Loggly, Inc.
San Francisco, CA

Mime
View raw message