incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wangpei (Peter)" <peter.wang...@huawei.com>
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 [mailto:jbellis@gmail.com] 
发送时间: 2011年3月10日 10:19
收件人: user@cassandra.apache.org
主题: Re: understanding tombstones

On Wed, Mar 9, 2011 at 4:54 PM, Jeffrey Wang <jwang@palantir.com> 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.

Right.

> 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
http://www.datastax.com
Mime
View raw message