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 4A34DD84D for ; Thu, 8 Nov 2012 12:53:53 +0000 (UTC) Received: (qmail 77431 invoked by uid 500); 8 Nov 2012 12:53:51 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 77171 invoked by uid 500); 8 Nov 2012 12:53:50 -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 77145 invoked by uid 99); 8 Nov 2012 12:53:49 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Nov 2012 12:53:49 +0000 X-ASF-Spam-Status: No, hits=2.8 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of arodrime@gmail.com designates 209.85.212.44 as permitted sender) Received: from [209.85.212.44] (HELO mail-vb0-f44.google.com) (209.85.212.44) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Nov 2012 12:53:42 +0000 Received: by mail-vb0-f44.google.com with SMTP id fc26so2963748vbb.31 for ; Thu, 08 Nov 2012 04:53:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=RkcKOQVfWWu9c3n4aMDkYinfFJ0a7C6bPfatmgTMwYU=; b=uv4KQAGKH8wpwAGzMutlpSQVlXpv79um3KC9JeF5rjUlTy934me3eCEtm59hplczcP 5wvEUxM+WB6YMl554rWwb7ch80SN5QmuvzICQmBux9uwpVh71a6crXz1gjF8+E6YuBIf Rd/MrBzsHRLJ8+xEg/BpwPE49XJJVeZCwIBYji4MbHebIyzEbb3s26+Xm30RLhDQHAFL uzitEhsheI6CfTR7lGJ6Noa1Y46BL+9PRiiqw148nthNosvHvdTlqMLlCR8aKmjmDgky EtM8gdBP496hYW2jk4rTlfYpwsejzEPO8UZsyGZA6pRzWPc+zVNqmmEjfBmlUvCOohaa Dt2Q== Received: by 10.58.116.212 with SMTP id jy20mr1889242veb.5.1352379201980; Thu, 08 Nov 2012 04:53:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.249.3 with HTTP; Thu, 8 Nov 2012 04:53:01 -0800 (PST) In-Reply-To: References: From: Alain RODRIGUEZ Date: Thu, 8 Nov 2012 13:53:01 +0100 Message-ID: Subject: Re: Compact and Repair To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=047d7b6d99a4ef873804cdfb51c5 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b6d99a4ef873804cdfb51c5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Did you change the RF or had a node down since you repaired last time ? 2012/11/8 Henrik Schr=F6der > No, we're not using columns with TTL, and I performed a major compaction > before the repair, so there shouldn't be vast amounts of tombstones movin= g > around. > > And the increase happened during the repair, the nodes gained ~20-30GB > each. > > > /Henrik > > > > On Thu, Nov 8, 2012 at 12:40 PM, horschi wrote: > >> Hi, >> >> is it possible that your repair is overrepairing due to any of the issue= s >> discussed here: >> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/repair-= compaction-and-tombstone-rows-td7583481.html? >> >> >> I've seen repair increasing the load on my cluster, but what you are >> describing sounds like a lot to me. >> >> Does this increase happen due to repair entirely? Or was the load maybe >> increasing gradually over the week and you just checked for the first ti= me? >> >> cheers, >> Christian >> >> >> >> On Thu, Nov 8, 2012 at 11:55 AM, Henrik Schr=F6der wr= ote: >> >>> Hi, >>> >>> We recently ran a major compaction across our cluster, which reduced th= e >>> storage used by about 50%. This is fine, since we do a lot of updates t= o >>> existing data, so that's the expected result. >>> >>> The day after, we ran a full repair -pr across the cluster, and when >>> that finished, each storage node was at about the same size as before t= he >>> major compaction. Why does that happen? What gets transferred to other >>> nodes, and why does it suddenly take up a lot of space again? >>> >>> We haven't run repair -pr regularly, so is this just something that >>> happens on the first weekly run, and can we expect a different result n= ext >>> week? Or does repair always cause the data to grow on each node? To me = it >>> just doesn't seem proportional? >>> >>> >>> /Henrik >>> >> >> > --047d7b6d99a4ef873804cdfb51c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Did you change the RF or had a node down since you repaired last time ?

2012/11/8 Henrik = Schr=F6der <skrolle@gmail.com>
No, we're not using columns with TTL, an= d I performed a major compaction before the repair, so there shouldn't = be vast amounts of tombstones moving around.

And the increase happened during the repair, the nodes gained ~20-30GB = each.


/Henrik



On Thu, Nov 8, = 2012 at 12:40 PM, horschi <horschi@gmail.com> wrote:
Hi,

is it possible that your repair i= s overrepairing due to any of the issues discussed here: http://cassandra-user= -incubator-apache-org.3065146.n2.nabble.com/repair-compaction-and-tombstone= -rows-td7583481.html ?


I've seen repair increasing the load on my cluster, but what yo= u are describing sounds like a lot to me.

Does this increase happen = due to repair entirely? Or was the load maybe increasing gradually over the= week and you just checked for the first time?

cheers,
Christian



On= Thu, Nov 8, 2012 at 11:55 AM, Henrik Schr=F6der <skrolle@gmail.com>= ; wrote:
Hi,

We recently ran a major compactio= n across our cluster, which reduced the storage used by about 50%. This is = fine, since we do a lot of updates to existing data, so that's the expe= cted result.

The day after, we ran a full repair -pr across the cluster, and when th= at finished, each storage node was at about the same size as before the maj= or compaction. Why does that happen? What gets transferred to other nodes, = and why does it suddenly take up a lot of space again?

We haven't run repair -pr regularly, so is this just something that= happens on the first weekly run, and can we expect a different result next= week? Or does repair always cause the data to grow on each node? To me it = just doesn't seem proportional?


/Henrik



--047d7b6d99a4ef873804cdfb51c5--