Re: Does replicate_on_write=true imply that CL.QUORUM for reads is unnecessary?

[Andrew Bialecki <an...@gmail.com>]

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 <sy...@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
>> <an...@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)
>>
>
>