Thanks for the clarifications. For future readers, the details of write requests are well documented at http://www.datastax.com/docs/1.2/cluster_architecture/about_client_requests#about-write-requests.


On Fri, May 31, 2013 at 4:20 AM, Sylvain Lebresne <sylvain@datastax.com> wrote:
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).

--
Sylvain


On Fri, May 31, 2013 at 9:20 AM, Peter Schuller <peter.schuller@infidyne.com> 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
<andrew.bialecki@gmail.com> wrote:
> To answer my own question, directly from the docs:
> http://www.datastax.com/docs/1.0/configuration/storage_configuration#replicate-on-write.
> 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 <andrew.bialecki@gmail.com>
> 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 CL.QUORUM
>> 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, http://worldmodscode.wordpress.com)