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 65FEDD379 for ; Sat, 2 Mar 2013 20:44:29 +0000 (UTC) Received: (qmail 56052 invoked by uid 500); 2 Mar 2013 20:44:26 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 56011 invoked by uid 500); 2 Mar 2013 20:44: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 56003 invoked by uid 99); 2 Mar 2013 20:44:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Mar 2013 20:44:26 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jcistaro@netflix.com designates 69.53.237.162 as permitted sender) Received: from [69.53.237.162] (HELO exout103.netflix.com) (69.53.237.162) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Mar 2013 20:44:20 +0000 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=s2048;d=netflix.com; h=from:to:subject:date:message-id:in-reply-to:content-type:mime-version; bh=dLLUQoIijPud1yUdq+dF7tMpIBo=; b=RmI7P/9PKDWElqTWzfct2GugvhzwSI1PsOnRZFQXbZygRKCMN5i01EKXIuNwyKZ/7VV0m7Fn D3dgW96dsTkjixDm7IoG/1uuzYkUQeeoDY7QNBzrFYzbjMZemWITigMQlmonGvTlvb0UBQLA 2GurAVNsG4gmUZhvp8VFv+jSoB3ohNCiLNWSg/ZpoH9tbdgfZtlN4HjjNxZiWOmNGIZpXzT0 OHc+7sup/01JXykSDp8Py2N21Y7phuDV57RlRm0bv8pcGv6H/HNEW9Htg0C/JAJQD0DoAnGC 4I+tv49wnmTM93ef4WiL1M9MTllJ5mZBHvsv+rDiAIkIHOv+E21Ekg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048;d=netflix.com; h=from:to:subject:date:message-id:in-reply-to:content-type:mime-version; b=eqLWqJr8U+RxBv7GuKD7vdk4fR16RS8jcmOe1PAuF7XixL+dDWLnn5+sSZWG6kUktQuC4UVX cqQ4PIS869n04QCAeimRYcJwCjFZAmZgR+K2zqqVSi+G54Nxyu5i9/3kR3aY9qg8ZYIHARv6 i7Cy9rPGnTG/NdWlZxfQtR54OOdTrb9RKu/FncdbwAMLvzGE+pZbr8bX60Cezg41r3lqf9aE 0Hlx5PdnBcU1mKfA4QbxR3ZC5ICwxPz71+0j2JKlYQJyzuVrAJGlnolS4HH4YPTWCAs/LnTu 1rqmqfmvTSt/zs6kp1NHfVGHmXRDLP1onHdb/F3ejphqdE8RoT2e+Q== Received: from EXFE104.corp.netflix.com (10.64.32.104) by exout103.netflix.com (10.64.240.73) with Microsoft SMTP Server (TLS) id 14.2.298.4; Sat, 2 Mar 2013 12:44:01 -0800 Received: from EXMB102.corp.netflix.com ([169.254.2.85]) by exfe104.corp.netflix.com ([10.64.32.104]) with mapi id 14.02.0283.003; Sat, 2 Mar 2013 12:43:58 -0800 From: Jim Cistaro To: "user@cassandra.apache.org" Subject: Re: -pr vs. no -pr Thread-Topic: -pr vs. no -pr Thread-Index: Ac4WBGkK7RK45tnRRmiBfDklLufn5gAr6g4AAASLyAAAMBosgA== Date: Sat, 2 Mar 2013 20:43:58 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.64.27.13] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9AEB8147725CD04391CC63048E75E622@netflix.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org One other slight advantage of -pr=8A We sometimes have repairs that hang and need to be killed and restarted. -pr means you have to "redo" a fraction of the work. jc -----Original Message----- From: , Dean Reply-To: "user@cassandra.apache.org" Date: Friday, March 1, 2013 5:46 AM To: "user@cassandra.apache.org" Subject: Re: -pr vs. no -pr >Sweeet, I %100 understand this now from these last few emails. It has >always been a bit confusing. > >Thanks, >Dean > >From: Sylvain Lebresne > >Reply-To: "user@cassandra.apache.org" >> >Date: Friday, March 1, 2013 4:36 AM >To: "user@cassandra.apache.org" >> >Subject: Re: -pr vs. no -pr > >On Thu, Feb 28, 2013 at 11:39 PM, Hiller, Dean >> wrote: >Isn't it true if I have 6 nodes, I could run nodetool repair on just 2 >nodes(RF=3D3) instead of using nodetool repair =ADpr??? > >Yes, it is true. > >And to precise further, in your case you have 2 options: > 1) doing repair *without* -pr on 2 nodes (assuming you pick the correct >2 nodes, it's *not* any 2 nodes) > 2) doing a repair *with* -pr on the 6 nodes > >Both of those cases would 1) repair the full ring and 2) do the same >amount of work. > >What is the advantage of =ADpr then? > >As it happens, your case is a special case. You have a number of node >that is a multiple of your replication factor. Now if that wasn't the >case (say 5, 7 or 8 nodes with RF=3D3), then there is *no way* you can >repair *without* -pr the whole cluster without doing *more* work than by >doing a repair *with* -pr on all nodes. > >So the advantages of --pr (which btw, should be use for repair the whole >cluster, not when you want to rebuild a specific node) are: > 1) it always do the minimum of work, while repair without --pr is >wasteful if the number of nodes is not a multiple of the replication >factor (no matter how smart you are at scheduling the repairs). > 2) even if your number of nodes is a multiple of the replication factor, >you still have to make sure you pick the right N/RF nodes to repair if >you don't use -pr. If you don't pick the correct ones, you will not >repair the full ring. Using -pr is much more shoot-footing free: you have >to run it on every node, period. > >-- >Sylvain >