Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4EB86692F for ; Thu, 30 Jun 2011 20:47:48 +0000 (UTC) Received: (qmail 89918 invoked by uid 500); 30 Jun 2011 20:47:46 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 89874 invoked by uid 500); 30 Jun 2011 20:47:45 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 89866 invoked by uid 99); 30 Jun 2011 20:47:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Jun 2011 20:47:45 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of edlinuxguru@gmail.com designates 209.85.210.172 as permitted sender) Received: from [209.85.210.172] (HELO mail-iy0-f172.google.com) (209.85.210.172) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Jun 2011 20:47:37 +0000 Received: by iye7 with SMTP id 7so2875480iye.31 for ; Thu, 30 Jun 2011 13:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XznZvmUizNy62KTTbcvt6KsjVmyVJN/syQG9KyGKY3k=; b=hVjdUlBJBv8d+WYwvPm+j83oHxxuLZ1Rw45uPegMTQLCs7G3qntvfMs3st/Wxn3JK8 85oO0fu1DQNwHcoaCSZhPq1VbJCSp4QQbjfFHs6/NTXdk5WUG6UjIeU6PYVqvBHwU1CQ sC/m4EkwZS2QMUfUIg5LP4w/eHHM+DI2izVtI= MIME-Version: 1.0 Received: by 10.42.97.136 with SMTP id o8mr2066552icn.222.1309466836242; Thu, 30 Jun 2011 13:47:16 -0700 (PDT) Received: by 10.42.173.198 with HTTP; Thu, 30 Jun 2011 13:47:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jun 2011 16:47:16 -0400 Message-ID: Subject: Re: Meaning of 'nodetool repair has to run within GCGraceSeconds' From: Edward Capriolo To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=485b397dd1039e911b04a6f4010b X-Virus-Checked: Checked by ClamAV on apache.org --485b397dd1039e911b04a6f4010b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 30, 2011 at 4:25 PM, A J 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. --485b397dd1039e911b04a6f4010b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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#Fre= quency_of_nodetool_repair
is not very clear to me.

How can a delete be 'unforgotten' if I don't run nodetool repai= r? (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/DistributedDel= etes
)
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 write= s/tomstones with TimedoutException do not get hinted even if HH is on. https://is= sues.apache.org/jira/browse/CASSANDRA-2034. Thus tombstones can get los= t.

Because of this the only way to find lost tombstones is to anti-e= ntropy repair. If you do not repair in the gc period a node could lose a to= mbstone 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.

--485b397dd1039e911b04a6f4010b--