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: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
