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 86D8E8BB3 for ; Thu, 18 Aug 2011 23:01:01 +0000 (UTC) Received: (qmail 63961 invoked by uid 500); 18 Aug 2011 22:45:27 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 63940 invoked by uid 500); 18 Aug 2011 22:45:26 -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 63931 invoked by uid 99); 18 Aug 2011 22:45:25 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Aug 2011 22:45:25 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a42.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Aug 2011 22:45:18 +0000 Received: from homiemail-a42.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a42.g.dreamhost.com (Postfix) with ESMTP id EB2FA68C06B for ; Thu, 18 Aug 2011 15:44:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=thelastpickle.com; h=from :mime-version:content-type:subject:date:in-reply-to:to :references:message-id; q=dns; s=thelastpickle.com; b=gKOhp4JrRa BfvSu5+Bds0IYkx16l3pUWKFtJb+9W9cOnYZKaQ77HHI0DKUrAE0U2MDATqxcvEI OtkDox9rEaTkoSeYudSyvfD+xWM5pEMGsOLoNvVCi5s4VFoNG11SsMmjeKeZ2wzW RGYo4YJsxSpSiH+yEV0K1WM0uwS28g5X4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h=from :mime-version:content-type:subject:date:in-reply-to:to :references:message-id; s=thelastpickle.com; bh=mdOtzsXS3x333pQz t7BSimAF3JY=; b=RAmVdrPcKjZn+DpjPfS15qmA6ycDKmz/mB1cEgTbFFxyixlH UTA0iS2ADKhFU0DD/+NlPoQcBhYK4+AEfG/1OZ1dFQmui9/1elRUPYGLayRXtzI0 Z4DEpWJeAzI0abUZoX9saurfuujGgmgsaCzJXKxW0ELpE+yXC/LbCrsW2s4= Received: from [172.16.1.2] (219-89-2-67.dialup.xtra.co.nz [219.89.2.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a42.g.dreamhost.com (Postfix) with ESMTPSA id 3E46A68C065 for ; Thu, 18 Aug 2011 15:44:56 -0700 (PDT) From: aaron morton Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_51F7C8E2-1E28-40D5-8C31-D1EEED9B1CE7" Subject: Re: nodetool repair caused high disk space usage Date: Fri, 19 Aug 2011 10:44:52 +1200 In-Reply-To: To: user@cassandra.apache.org References: Message-Id: X-Mailer: Apple Mail (2.1244.3) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_51F7C8E2-1E28-40D5-8C31-D1EEED9B1CE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 No scrub is a local operation only.=20 Cheers ----------------- Aaron Morton Freelance Cassandra Developer @aaronmorton http://www.thelastpickle.com On 19/08/2011, at 6:36 AM, Huy Le wrote: > Thanks. I won't try that then. >=20 > So in our environment, after upgrading from 0.6.11 to 0.8.4, we have = to run scrub on all nodes before we can run repair on them. Is there = any chance that running scrub on the nodes causing data from all = SSTables being streamed to/from other nodes on running repair? >=20 > Huy >=20 > On Thu, Aug 18, 2011 at 10:22 AM, Philippe = wrote: > Unfortunately repairing one cf at a time didn't help in my case = because it still streams all CF and that triggers lots of compactions >=20 > On Aug 18, 2011 3:48 PM, "Huy Le" wrote: >=20 >=20 >=20 > --=20 > Huy Le=20 > Spring Partners, Inc. > http://springpadit.com=20 --Apple-Mail=_51F7C8E2-1E28-40D5-8C31-D1EEED9B1CE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 No = scrub is a local operation = only. 

Cheers

http://www.thelastpickle.com

On 19/08/2011, at 6:36 AM, Huy Le wrote:

Thanks.  I won't try that then.

So in our = environment, after upgrading from 0.6.11 to 0.8.4, we have to run scrub = on all nodes before we can run repair on them.  Is there any chance = that running scrub on the nodes causing data from all SSTables being = streamed to/from other nodes on running repair?

Huy

On Thu, Aug 18, 2011 at 10:22 = AM, Philippe <watcherfr@gmail.com> = wrote:

Unfortunately = repairing one cf at a time didn't help in my case because it still = streams all CF and that triggers lots of compactions

On Aug 18, 2011 3:48 PM, "Huy Le" <huyle@springpartners.com> wrote:



--
Huy Le
Spring = Partners, Inc.
http://springpadit.com

= --Apple-Mail=_51F7C8E2-1E28-40D5-8C31-D1EEED9B1CE7--