cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Coli <rc...@eventbrite.com>
Subject Re: Read Repair
Date Wed, 08 Jul 2015 22:06:46 GMT
On Wed, Jul 8, 2015 at 2:07 PM, Saladi Naidu <naidusp2002@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

Mime
View raw message