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.comwrote:
I agree, the
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,
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
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
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
