Hi Jaydeep,

Yes, dealing with tombstones in Cassandra is very tricky.

Cassandra keeps tombstones to mark deleted columns and distribute (hinted
handoff, full repair, read repair ...) to the other nodes that missed the
initial remove request. But Cassandra can't afford to keep those tombstones
lifetime and has to wipe them. The tradeoff is that after a time,
GCGraceSeconds, configured on each column family, the tombstones are fully
dropped during compactions and are not distributed to the other nodes
If one node didn't have the chance to receive this tombstone during this
period, and kept and old column value, then the deleted column will

So I guess in your case that the time T2 is older than this GCGraceSeconds ?

The best way to avoid all those phantom columns to come back from death is
to run a full repair on your cluster at least once every GCGraceSeconds.
Did you try this?


Le sam. 17 sept. 2016 à 00:05, Jaydeep Chovatia <chovatia.jayd...@gmail.com>
a écrit :

> Hi,
> We have three node (N1, N2, N3) cluster (RF=3) and data in SSTable as
> following:
> N1:
> SSTable: Partition key K1 is marked as tombstone at time T2
> N2:
> SSTable: Partition key K1 is marked as tombstone at time T2
> N3:
> SSTable: Partition key K1 is valid and has data D1 with lower time-stamp
> T1 (T1 < T2)
> Now when I read using quorum then sometimes it returns data D1 and
> sometimes it returns empty results. After tracing I found that when N1 and
> N2 are chosen then we get empty data, when (N1/N2) and N3 are chosen then
> D1 data is returned.
> My point is when we read with Quorum then our results have to be
> consistent, here same query give different results at different times.
> Isn't this a big problem with Cassandra @QUORUM (with tombstone)?
> Thanks,
> Jaydeep

Reply via email to