2011/3/10 Wangpei (Peter) <peter.wang...@huawei.com> > 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? >
No, the client won't get the row unless you have set an unreasonable value to gc_grace_seconds (like 0 in the example of the first mail of this thread, that is *not* a value you should use). Cassandra prevents this using the gc_grace_seconds option, see http://wiki.apache.org/cassandra/DistributedDeletes for more details. -- Sylvain > > -----邮件原件----- > 发件人: Jonathan Ellis [mailto:jbel...@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 <jw...@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 >
