cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <edlinuxg...@gmail.com>
Subject Re: Meaning of 'nodetool repair has to run within GCGraceSeconds'
Date Thu, 30 Jun 2011 20:47:16 GMT
On Thu, Jun 30, 2011 at 4:25 PM, A J <s5alye@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.

Mime
View raw message