One thing to note is that the exception you get... in this case, you'll get a timeout, not a failure. i.e. as far as Cassandra is concerned, the write is still ongoing - it hasn't failed; but from the client's perspective, it's timed out. In this case (i.e. timeout), the application would usually retry - which would likely get a failure instead of timeout as by then, the coordinator would know of down nodes. In this case, saving with reduced consistency level is usually good enough, as that data will get replicated as nodes rejoin / new nodes are added.
Date: Wed, 8 Jul 2015 15:06:46 -0700 Subject: Re: Read Repair From: rc...@eventbrite.com To: user@cassandra.apache.org; naidusp2...@yahoo.com On Wed, Jul 8, 2015 at 2:07 PM, Saladi Naidu <naidusp2...@yahoo.com> wrote: Suppose I have a row of existing data with set of values for attributes I call this State1, and issue an update to some columns with Quorum consistency. If the write is succeeded in one node, Node1 and and failed on remaining nodes. As there is no Rollback, Node1 row attributes will remain new state, State2 and rest of the nodes row will have old state, State1. If I do a Read and Cassandra detects state difference, it will issue a Read repair which will result in new state, State2 being propagated to other nodes. But from a application point of view the update never happened because it received an exception. Yes, that's correct. This is the property I call "coalescing to an un-acknowledged-write," which is extremely unusual to find in non-distributed, non-log-structured databases. How to handle this kind of a situation? Design your application in such a way that operations are idempotent and therefore retryable on failure. =Rob
