On Thu, Jun 30, 2011 at 4:25 PM, A J <s5a...@gmail.com> wrote: > I am little confused of the reason why nodetool repair has to run > within GCGraceSeconds. > > The documentation at: > http://wiki.apache.org/cassandra/Operations#Frequency_of_nodetool_repair > is not very clear to me. > > How can a delete be 'unforgotten' if I don't run nodetool repair? (I > understand that if a node is down for more than GCGraceSeconds, I > should not get it up without resynching is completely. Otherwise > deletes may reappear.http://wiki.apache.org/cassandra/DistributedDeletes > ) > But not sure how exactly nodetool repair ties into this mechanism of > distributed deletes. > > Thanks for any clarifications. >
Read repair does NOT repair tombstones. Failed writes/tomstones with TimedoutException do not get hinted even if HH is on. https://issues.apache.org/jira/browse/CASSANDRA-2034. Thus tombstones can get lost. Because of this the only way to find lost tombstones is to anti-entropy repair. If you do not repair in the gc period a node could lose a tombstone and the row could be read repaired and resurrected. In our case, we are lucky, we delete rows when they get old and stale. While it is not great if a deleted row appears it is not harmful thus I can live with less repairing then most.
