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 923E018779 for ; Mon, 17 Aug 2015 18:31:26 +0000 (UTC) Received: (qmail 92206 invoked by uid 500); 17 Aug 2015 18:31:23 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 92164 invoked by uid 500); 17 Aug 2015 18:31:23 -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 92145 invoked by uid 99); 17 Aug 2015 18:31:23 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Aug 2015 18:31:23 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 60C701AA38E for ; Mon, 17 Aug 2015 18:31:23 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3 X-Spam-Level: *** X-Spam-Status: No, score=3 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=3] autolearn=disabled Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id r97PF5ab0HFI for ; Mon, 17 Aug 2015 18:31:08 +0000 (UTC) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id C418142B29 for ; Mon, 17 Aug 2015 18:31:07 +0000 (UTC) Received: by lagz9 with SMTP id z9so84709803lag.3 for ; Mon, 17 Aug 2015 11:31:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=oL3o4WtVsqw9IjIUSFAWeGY0kds6pjE+U840Pzbxywk=; b=d187lcbXUguFtb+3QtD7UjB/5uSFfpqCMoixpQRnJT9ehhqWdZnFG8EwnuHIsFIPCp aw4vUQwphla03UGKFDG36fwtF+cqbDAJhUVAxNpZD/Q0KUMMMLFzZwV3rtKggTyS82tk nIP7HFf74mEA2UaynRmib5uSw1StfKhSIIRiXNd3DJtZHYTi5NY4EE+dL5ZHWTpKSciF mpVKEwFWAXqqwia2ENuzBa2GvsbR+lVtG75I3NUZW9n1wGgRLcnC50hIq2fqjPcwrfx2 OfgcW3lxGLEZV4JcAsay6BDcOZD1kmYF2UPdwPQdS98SvZwMYXBtHlA/thj01SUiIujX BrGA== X-Gm-Message-State: ALoCoQns3qAOou7B2be2CnTEdHKsjAbjS+UfbCeeakODtd0VAolz7MUPmwywAbW7ieqANVHvaAag MIME-Version: 1.0 X-Received: by 10.112.16.225 with SMTP id j1mr2170968lbd.118.1439836266697; Mon, 17 Aug 2015 11:31:06 -0700 (PDT) Received: by 10.114.64.201 with HTTP; Mon, 17 Aug 2015 11:31:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 17 Aug 2015 11:31:06 -0700 Message-ID: Subject: Re: Parallel repairs From: Robert Coli To: "user@cassandra.apache.org" Content-Type: multipart/alternative; boundary=001a11c3cb62363047051d8601eb --001a11c3cb62363047051d8601eb Content-Type: text/plain; charset=UTF-8 On Mon, Aug 17, 2015 at 8:50 AM, Stan Lemon wrote:, > > Thanks for the reply. I do have vnodes. I was not aware of the -par flag > on the repair command, I was actually referring to have repair run on both > nodes A & B at the same time. It sounds like though, that I should > probably be using this -par flag but to do it per node sequentially one > after the other? > That's what I was suggesting, yes. > Right now just running 'nodetool repair' on one node is taking ~3.5 days, > with 24 nodes I am now starting to question whether or not I should be > increasing gc_grace_second to be much longer than the default 10 days since > it's going to take longer than 10 days to repair the whole cluster. > Yep, I personally recommend setting it to 34 days and then kicking off repair on the first of the month. That way you have been 3 and 7 days for it to complete, which should in most cases be enough time. Have you unthrottled compaction and etc.? 10 days is a long time... =Rob --001a11c3cb62363047051d8601eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Aug 17, 2015 at 8:50 AM, Stan Lemon <slemon@salesforce.com>= wrote:,
Thanks = for the reply.=C2=A0 I do have vnodes.=C2=A0 I was not aware of the -par fl= ag on the repair command, I was actually referring to have repair run on bo= th nodes A & B at the same time.=C2=A0 It sounds like though, that I sh= ould probably be using this -par flag but to do it per node sequentially on= e after the other?

That's w= hat I was suggesting, yes.
=C2=A0
Right now just running 'nodetool repair'= on one node is taking ~3.5 days, with 24 nodes I am now starting to questi= on whether or not I should be increasing gc_grace_second to be much longer = than the default 10 days since it's going to take longer than 10 days t= o repair the whole cluster.

Yep= , I personally recommend setting it to 34 days and then kicking off repair = on the first of the month. That way you have been 3 and 7 days for it to co= mplete, which should in most cases be enough time.

Have you unthrottled compaction and etc.? 10 days is a long time...

=3DRob

--001a11c3cb62363047051d8601eb--