Retry is the best option. Because the read repair will fix it on a subsequent read and it will actually fix it with a value that was actually deemed a failed write to the client.
A read repair will fix it immediately after the first read of the row.
On 2010-04-08 16:36, Mark Greene wrote:
> So unless you re-try the write, the previous stale write stays on the
> other two nodes? Would a read repair fix this eventually?
> On Thu, Apr 8, 2010 at 11:36 AM, Avinash Lakshman
> <email@example.com <mailto:firstname.lastname@example.org>> wrote:
> What your describing is a distributed transaction? Generally strong
> consistency is always associated with doing transactional writes
> where you never see the results of a failed write on a subsequent
> read no matter what happens. Cassandra has no notion of rollback.
> That is why no combination will give you strong consistency. The
> idea is you re-try the failed write and eventually the system would
> have gotten rid of the previous stale write.
> On Thu, Apr 8, 2010 at 8:29 AM, Jeremy Dunck <email@example.com
> <mailto:firstname.lastname@example.org>> wrote:
> On Thu, Apr 8, 2010 at 7:16 AM, Gary Dusbabek
> <email@example.com <mailto:firstname.lastname@example.org>> wrote:
> > On Thu, Apr 8, 2010 at 02:55, Paul Prescod <email@example.com
--> <mailto:firstname.lastname@example.org>> wrote:
> >> In this¹ debate, there seemed to be consensus on the
> following fact:
> >> "In Cassandra, say you use N=3, W=3 & R=1. Let’s say you
> managed to
> >> only write to replicas A & B, but not C. In this case
> Cassandra will
> >> return an error to the application saying the write failed-
> which is
> >> acceptable given than W=3. But Cassandra does not
> cleanup/rollback the
> >> writes that happened to A & B."
> > correct: no rolling back. Cassandra does go out of its way to
> > sure the cluster is healthy enough to begin the write though.
> I think the general answer here is don't use R=1 if you can't
> inconsistency? Still the point of confusion -- if W=3 and the write
> succeeds on 2 nodes but fails the 3rd, the write fails (to the
> updating client), but is the data on the two successful nodes still
> readable (i.e. reading from what was actually a failed write)?
| +1 512 577 5827 [mobile]
| +1 512 454 6659 [office]
| +1 512 870 8453 [direct]