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 <sylv...@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.schul...@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.biale...@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.biale...@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) >> > >