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)
