From user-return-16448-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Thu May 5 06:52:47 2011 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 134742237 for ; Thu, 5 May 2011 06:52:47 +0000 (UTC) Received: (qmail 71549 invoked by uid 500); 5 May 2011 06:52:45 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 71282 invoked by uid 500); 5 May 2011 06:52:44 -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 71261 invoked by uid 99); 5 May 2011 06:52:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 May 2011 06:52:42 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of tyler@datastax.com designates 74.125.82.44 as permitted sender) Received: from [74.125.82.44] (HELO mail-ww0-f44.google.com) (74.125.82.44) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 May 2011 06:52:36 +0000 Received: by wwa36 with SMTP id 36so1783653wwa.25 for ; Wed, 04 May 2011 23:52:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.221.200 with SMTP id r50mr2117376wep.102.1304578335927; Wed, 04 May 2011 23:52:15 -0700 (PDT) Received: by 10.216.38.1 with HTTP; Wed, 4 May 2011 23:52:15 -0700 (PDT) X-Originating-IP: [66.68.100.77] In-Reply-To: References: <6536AD0871E35F4888BB090DD6ECF4806CD393634E@AMRXM3124.dir.svc.accenture.com> <3212236C-109C-46CF-A217-EAD2FE4E3686@thelastpickle.com> Date: Thu, 5 May 2011 01:52:15 -0500 Message-ID: Subject: Re: Decommissioning node is causing broken pipe error From: Tyler Hobbs To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=0016364d22a74b6e4e04a281d01c X-Virus-Checked: Checked by ClamAV on apache.org --0016364d22a74b6e4e04a281d01c Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 5, 2011 at 1:21 AM, Peter Schuller wrote: > > It's no longer recommended to run nodetool compact regularly as it can > mean > > that some tombstones do not get to be purged for a very long time. > > I think this is a mis-typing; it used to be that major compactions > were necessary to remove tombstones, but this is no longer the case in > 0.7 so that the need for major compactions is significantly lessened > or even eliminated. However, running major compactions won't cause > tombstones *not* to be removed; it's just not required *in order* for > them to be removed. > I think he was suggesting that any tombstones *left* in the large sstable generated by the major compaction won't be removed for a long time because that sstable itself will not participate in any minor compactions for a long time. (In general, rows in that sstable will not be merged for a long time.) -- Tyler Hobbs Software Engineer, DataStax Maintainer of the pycassa Cassandra Python client library --0016364d22a74b6e4e04a281d01c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, May 5, 2011 at 1:21 AM, Peter Schuller <= span dir=3D"ltr"><peter.s= chuller@infidyne.com> wrote:
> It's no longer recommended to run nodetool compa= ct regularly as it can mean
> that some tombstones do not get to be purged for a very long time.

I think this is a mis-typing; it used to be that major compactions were necessary to remove tombstones, but this is no longer the case in
0.7 so that the need for major compactions is significantly lessened
or even eliminated. However, running major compactions won't cause
tombstones *not* to be removed; it's just not required *in order* for them to be removed.

I think he was suggesting tha= t any tombstones *left* in the large sstable generated by the major compact= ion won't be removed for a long time because that sstable itself will n= ot participate in any minor compactions for a long time.=A0 (In general, ro= ws in that sstable will not be merged for a long time.)

--
Tyler Hobbs
Software Engineer, DataS= tax
Maintainer of the pycassa Cassandra Python client library
 --0016364d22a74b6e4e04a281d01c--