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 D5D789D5B for ; Mon, 12 Dec 2011 22:25:29 +0000 (UTC) Received: (qmail 11049 invoked by uid 500); 12 Dec 2011 22:25:27 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 11016 invoked by uid 500); 12 Dec 2011 22:25:27 -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 11008 invoked by uid 99); 12 Dec 2011 22:25:27 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Dec 2011 22:25:27 +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 (athena.apache.org: domain of tyler@datastax.com designates 209.85.215.44 as permitted sender) Received: from [209.85.215.44] (HELO mail-lpp01m010-f44.google.com) (209.85.215.44) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Dec 2011 22:25:19 +0000 Received: by laah2 with SMTP id h2so1567572laa.31 for ; Mon, 12 Dec 2011 14:24:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.128.103 with SMTP id nn7mr10929790lab.48.1323728697902; Mon, 12 Dec 2011 14:24:57 -0800 (PST) Received: by 10.152.18.138 with HTTP; Mon, 12 Dec 2011 14:24:57 -0800 (PST) In-Reply-To: References: Date: Mon, 12 Dec 2011 16:24:57 -0600 Message-ID: Subject: Re: Node repair : excessive data From: Tyler Hobbs To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=f46d04343e96d1482604b3ec9a9e --f46d04343e96d1482604b3ec9a9e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 12, 2011 at 3:47 PM, Brian Fleming wrote: > > However after the repair completed, we had over 2.5 times the original > load. Issuing a 'cleanup' reduced this to about 1.5 times the original > load. We observed an increase in the number of keys via 'cfstats' which is > obviously accounting for the increased load. > > Would anybody know why the repair pulled more keys in than it had > initially with the same token? How can we avoid this recurring? > Did you repair just prior to deleting the data directory? It's possible that your node was missing data that it was supposed to have before you started the test. -- Tyler Hobbs DataStax --f46d04343e96d1482604b3ec9a9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 12, 2011 at 3:47 PM, Brian Fleming <= span dir=3D"ltr"><bigbrianf= leming@gmail.com> wrote:

However after the repair completed, we had over 2.5 times the orig= inal load. =A0Issuing a 'cleanup' reduced this to about 1.5 times t= he original load. =A0We observed an increase in the number of keys via '= ;cfstats' which is obviously accounting for the increased load. =A0

Would anybody know why the repair pulled more keys in t= han it had initially with the same token? =A0How can we avoid this recurrin= g?

Did you repair just prior to deleting the da= ta directory?=A0 It's possible that your node was missing data that it = was supposed to have before you started the test.

--
Tyler Hobbs
DataStax
<= br> --f46d04343e96d1482604b3ec9a9e--