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 64A5D6B42 for ; Thu, 30 Jun 2011 20:25:59 +0000 (UTC) Received: (qmail 52077 invoked by uid 500); 30 Jun 2011 20:25:57 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 51994 invoked by uid 500); 30 Jun 2011 20:25:56 -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 51986 invoked by uid 99); 30 Jun 2011 20:25:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 30 Jun 2011 20:25:56 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of s5alye@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:25:50 +0000 Received: by iye7 with SMTP id 7so2858642iye.31 for ; Thu, 30 Jun 2011 13:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=aCGzUhurd4b1Ub3UCnXptL+1hg7IwHMmL1+Fnr2Tsjc=; b=CuJuGCrHSFXbASRFuKwdjifsgWgKjg8mu6DBFU/sVqM5RcMSD/w7c6sX2aOIqseoCL yofpJxZvsZRTErEx/DToAXuUu3PPg3ywaWgvFDpSI4g9rf5A51tzgw8t207Iy8TykmzR 0mDPinSrM2QchkC77EDu0+LyhmTk16oy9/aRg= MIME-Version: 1.0 Received: by 10.42.208.67 with SMTP id gb3mr2576058icb.423.1309465529864; Thu, 30 Jun 2011 13:25:29 -0700 (PDT) Received: by 10.231.14.4 with HTTP; Thu, 30 Jun 2011 13:25:29 -0700 (PDT) Date: Thu, 30 Jun 2011 16:25:29 -0400 Message-ID: Subject: Meaning of 'nodetool repair has to run within GCGraceSeconds' From: A J To: user@cassandra.apache.org Content-Type: text/plain; charset=ISO-8859-1 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.