incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wangpei (Peter)" <>
Subject Re: understanding tombstones
Date Thu, 10 Mar 2011 11:20:40 GMT
My question: 
what the client would get, when following happens:(RF=3, N=3)
1, write with timestamp T and succeed in all nodes.
2, delete with timestamp T+1, CL=Q, and succeed in node1 and node2 but failed in node3.
3, force flush + compaction
4, read CL=Q

Does the client will get the row and read repair will "fix" the data?
If not, how cassandra prevent from this?

发件人: Jonathan Ellis [] 
发送时间: 2011年3月10日 10:19
主题: Re: understanding tombstones

On Wed, Mar 9, 2011 at 4:54 PM, Jeffrey Wang <> wrote:
> insert row X with timestamp T
> delete row X with timestamp T+1
> force flush + compaction
> insert row X with timestamp T
> My understanding is that the tombstone created by the delete (and row X)
> will disappear with the flush + compaction which means the last insertion
> should show up.


> I believe I have traced this to the fact that the markedForDeleteAt field on
> the ColumnFamily does not get reset after a compaction (after
> gc_grace_seconds has passed); is this desirable? I think it introduces an
> inconsistency in how tombstoned columns work versus tombstoned CFs. Thanks.

That does sound like a bug.  Can you create a ticket?

Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
View raw message