incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Lebresne <>
Subject Re: Does replicate_on_write=true imply that CL.QUORUM for reads is unnecessary?
Date Fri, 31 May 2013 08:20:26 GMT
I agree, the page is clearly misleading in its formulation.

However, for the sake of being precise, I'll note that it is not untrue
strictly speaking.
If replicate_on_write is true (the default that you should probably not
change unless you consider yourself an expert in the Cassandra counters
implementation), the a write will be written to all replica, and that does
not depend of the consistency level of the operation.
*But*, please note that this is also true for *every* other write in
Cassandra. I.e. for non-counters writes, we *always* replicate the write to
every replica regardless of the consistency level. The only thing the CL
change is how many acks from
said replica we wait for before returning a success to the client. And it
works the exact same way for counters with replicate_on_write.

Or put another way, by default, counters works exactly as normal writes as
far CL is concerned. So no, replicate_on_write does *not* set the CL to ALL
regardless of what you set.
However, if you set replicate_on_write to false, we will only write the
counter to 1 replica. Which means that the only CL that you will be able to
use for writes is ONE (we don't allow ANY for counters).


On Fri, May 31, 2013 at 9:20 AM, Peter Schuller <
> wrote:

> This is incorrect. IMO that page is misleading.
> replicate on write should normally always be turned on, or the change
> will only be recorded on one node. Replicate on write is asynchronous
> with respect to the request and doesn't affect consistency level at
> all.
> On Wed, May 29, 2013 at 7:32 PM, Andrew Bialecki
> <> wrote:
> > To answer my own question, directly from the docs:
> >
> .
> > It appears the answer to this is: "Yes, CL.QUORUM isn't necessary for
> > reads." Essentially, replicate_on_write sets the CL to ALL regardless of
> > what you actually set it to (and for good reason).
> >
> >
> > On Wed, May 29, 2013 at 9:47 AM, Andrew Bialecki <
> > wrote:
> >>
> >> Quick question about counter columns. In looking at the
> replicate_on_write
> >> setting, assuming you go with the default of "true", my understanding
> is it
> >> writes the increment to all replicas on any increment.
> >>
> >> If that's the case, doesn't that mean there's no point in using
> >> for reads because all replicas have the same values?
> >>
> >> Similarly, what effect does the read_repair_chance have on counter
> columns
> >> since they should need to read repair on write.
> >>
> >> In anticipation a possible answer, that both CL.QUORUM for reads and
> >> read_repair_chance only end up mattering for counter deletions, it's
> safe to
> >> only use CL.ONE and disable the read repair if we're never deleting
> >> counters. (And, of course, if we did start deleting counters, we'd need
> to
> >> revert those client and column family changes.)
> >
> >
> --
> / Peter Schuller (@scode,

View raw message