From user-return-15472-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Wed Apr 06 02:03:50 2011 Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 75022 invoked from network); 6 Apr 2011 02:03:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 6 Apr 2011 02:03:50 -0000 Received: (qmail 85681 invoked by uid 500); 6 Apr 2011 02:03:48 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 85652 invoked by uid 500); 6 Apr 2011 02:03:48 -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 85644 invoked by uid 99); 6 Apr 2011 02:03:48 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Apr 2011 02:03:48 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of watanabe.maki@gmail.com designates 209.85.161.44 as permitted sender) Received: from [209.85.161.44] (HELO mail-fx0-f44.google.com) (209.85.161.44) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Apr 2011 02:03:44 +0000 Received: by fxm15 with SMTP id 15so785804fxm.31 for ; Tue, 05 Apr 2011 19:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9pYebU9brp7doiCtZTXMvz57F+NmLlQLqCKiqvSjgU0=; b=NXsnnJtBxSzxUMraO04LV95hUH8uivby8fQgXDxGh5KbotjDGEvWRWdBkzFCCx9fFX mv5mAJjcH/svp7BWQ7wmBcTAX+7xdQ1MTla4Zr5qvKbM09+iElxffXBFLvWbN0bVVM9i U/hg9qgX/cOAKgTK01E4e8sTBJ2hRIQQ+zf5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=b19UMSY2ApFXWg/FBm6slsZ6d8GnbBQi1bejQNWThAE6hJ/UFN1evRMx94R8BNWeRx IhD4uqvAS4BOLJrCPSiAMBBuMFSi9/fI7cMKVfue3KzT2OCXewnWJXKQfJLKUxeIrbXZ pRrkgQxdwZXtX2+LfRgidPIyA7ezksFUuHa9c= MIME-Version: 1.0 Received: by 10.223.85.196 with SMTP id p4mr459450fal.5.1302055402749; Tue, 05 Apr 2011 19:03:22 -0700 (PDT) Received: by 10.223.96.13 with HTTP; Tue, 5 Apr 2011 19:03:22 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Apr 2011 11:03:22 +0900 Message-ID: Subject: Re: nodetool repair & compact From: Maki Watanabe To: Sylvain Lebresne Cc: user@cassandra.apache.org Content-Type: text/plain; charset=ISO-8859-1 Thanks Sylvain, it's very clear. But should I still need to force major compaction regularly to clear tombstones? I know that minor compaction clear the tombstones after 0.7, but maximumCompactionThreshold limits the maximum number of sstable which will be merged at once, so to GC all tombstones in all sstable in gc_grace_period, it is safe to run "nodetool compact" at least once in gc_grace_period, isn't it? maki 2011/4/6 Sylvain Lebresne : > On Tue, Apr 5, 2011 at 12:01 AM, Maki Watanabe wrote: >> Hello, >> On reading O'Reilly's Cassandra book and wiki, I'm a bit confusing on >> nodetool repair and compact. >> I believe we need to run nodetool repair regularly, and it synchronize >> all replica nodes at the end. >> According to the documents the "repair" invokes major compaction also >> (as side effect?). > > Those documents are wrong then. A repair does not trigger a major > compaction. The only thing that makes it similar to a major compaction is > that it will iterate over all the sstables. But for instance, you won't end > up with one big sstable at the end of repair as you would with a major > compaction. > >> Will this "major compaction" apply on replica nodes too? >> >> If I have 3 node ring and CF of RF=3, what should I do periodically on >> this system is: >> - nodetool repair on one of the nodes >> or >> - nodetool repair on one of the nodes, and nodetool compact on 2 of the nodes >> ? > > So as said, repair and compact are independent. You should > periodically run nodetool > repair (on one of your nodes in your case as you said). However, it is > not advised anymore > to run nodetool compact regularly unless you have a good reason to. > > -- > Sylvain >