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 A8D4A9D0C for ; Fri, 16 Mar 2012 09:38:01 +0000 (UTC) Received: (qmail 29368 invoked by uid 500); 16 Mar 2012 09:37:58 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 29300 invoked by uid 500); 16 Mar 2012 09:37:58 -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 29119 invoked by uid 99); 16 Mar 2012 09:37:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Mar 2012 09:37:58 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.215.44] (HELO mail-lpp01m010-f44.google.com) (209.85.215.44) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Mar 2012 09:37:53 +0000 Received: by lagj5 with SMTP id j5so3662008lag.31 for ; Fri, 16 Mar 2012 02:37:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:x-gm-message-state; bh=IEz6M0CTp5F+UGD0CW8udtVxamzAw97BV4MGmxuoYgA=; b=aZdDKvjQ8mbkIBty7gn2E74/E+KghSrJerN8Eo6hr3+EuI5U0oIrhY4mOZhqu1PTxF nDQzw/VcljaPHqCDdqaoLWPXPEdrrixJ23yVT1O560VQX8VpkJAj9jFIBxDi+7sFaHaO hfv+SaI7KDf7wGvYgQ4ycu/PIzkWwB8g8tc3820m3Eez93ztnAFPOmd8RRgiktS3IW6N ZTxGXjU6bZ60sxLOAkZd1HRv2fXEYpuOd7Zskyb+C/tSCQRD2aknq3e7lkvHZ17WdKmg HzbT6zNXIJ8SGZ3Fs3k2Hwan1q2q7GsqdPygI60KMb4VBC6y7wKlLRbufBb3Xp50UU+m 9WEg== Received: by 10.112.98.198 with SMTP id ek6mr75175lbb.4.1331890651395; Fri, 16 Mar 2012 02:37:31 -0700 (PDT) Received: from [192.168.2.50] (81-94-164-42.customer.itmastaren.net. [81.94.164.42]) by mx.google.com with ESMTPS id uc6sm5813743lbb.3.2012.03.16.02.37.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Mar 2012 02:37:30 -0700 (PDT) Message-ID: <4F6309D9.1030008@sitevision.se> Date: Fri, 16 Mar 2012 10:37:29 +0100 From: Mikael Wikblom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110920 SUSE/3.1.15 Thunderbird/3.1.15 MIME-Version: 1.0 To: user@cassandra.apache.org Subject: Re: Bootstrapping a new node to a running cluster References: <4F61AD41.6000800@sitevision.se> <9D70B73F-A79D-46E7-ACA7-6B4991A75739@thelastpickle.com> <4F61CE55.5050109@sitevision.se> <6D032969-6AC9-479C-A439-752545C4F035@thelastpickle.com> <4F62F226.50607@sitevision.se> <5945EFBB-042E-456B-BFFD-C83CF5497DCB@thelastpickle.com> In-Reply-To: <5945EFBB-042E-456B-BFFD-C83CF5497DCB@thelastpickle.com> Content-Type: multipart/alternative; boundary="------------000109010504000303060806" X-Gm-Message-State: ALoCoQnkERlWUa1rkeoPzkuLwrgxPrP+DSYp1BpZePSL2jxtECuL9RjUm56FZKZeB3L+UxgF77ZV X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------000109010504000303060806 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit ok, thank you for your time! Cheers On 03/16/2012 10:12 AM, aaron morton wrote: > I think your original plan is sound. > > 1. Up the RF to 4. > 2. Add the node with auto_bootstrap true > 3. Once bootrapping has finished the new node has all the data it needs. > 4. Check for secondary index creation using describe in the CLI to see > which are build. You can also see progress using nodetool compactionstats > >> I'm a bit puzzled though, I just tried to increase R to 3 in a >> cluster with N=2. It serves reads and writes without issues CL.one. >> Is the described restriction is something that will be implemented in >> the future? > I had a quick glance at the code. IIRC there was an explicit check if > RF > N, but I cannot find it any more. I'm guessing we now rely on a > normal UnavailableFailure if there are not enough UP nodes. > > Cheers > > ----------------- > Aaron Morton > Freelance Developer > @aaronmorton > http://www.thelastpickle.com > > On 16/03/2012, at 8:56 PM, Mikael Wikblom wrote: > >> ok, thank you both for the clarification. So the correct approach >> would be to bootstrap the new node and run repair on each of the >> nodes in the cluster. >> >> I'm a bit puzzled though, I just tried to increase R to 3 in a >> cluster with N=2. It serves reads and writes without issues CL.one. >> Is the described restriction is something that will be implemented in >> the future? >> >> Thank you >> Regards >> >> >> >> >> On 03/16/2012 03:07 AM, aaron morton wrote: >>> The documentation is correct. >>> I was mistakenly remembering discussions in the past about RF > #nodes. >>> >>> Cheers >>> >>> ----------------- >>> Aaron Morton >>> Freelance Developer >>> @aaronmorton >>> http://www.thelastpickle.com >>> >>> On 16/03/2012, at 4:34 AM, Doğan Çeçen wrote: >>> >>>>> I'm not sure why this is not allowed. As long as I do not use >>>>> CL.all there >>>>> will be enough nodes available to satisfy the read / write (at >>>>> least when I >>>>> look at ReadCallback and the WriteResponseHandler). Or am I missing >>>>> something here? >>>> >>>> According to >>>> http://www.datastax.com/docs/1.0/cluster_architecture/replication >>>> >>>> "As a general rule, the replication factor should not exceed the >>>> number of nodes in the cluster. However, it is possible to increase >>>> replication factor, and then add the desired number of nodes >>>> afterwards. When replication factor exceeds the number of nodes, >>>> writes will be rejected, but reads will be served as long as the >>>> desired consistency level can be met." >>>> >>>> -- >>>> () ascii ribbon campaign - against html e-mail >>>> /\ www.asciiribbon.org - against >>>> proprietary attachments >>> >> >> >> -- >> Mikael Wikblom >> Software Architect >> SiteVision AB >> 019-217058 >> mikael.wikblom@sitevision.se >> http://www.sitevision.se > -- Mikael Wikblom Software Architect SiteVision AB 019-217058 mikael.wikblom@sitevision.se http://www.sitevision.se --------------000109010504000303060806 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit ok, thank you for your time!

Cheers


On 03/16/2012 10:12 AM, aaron morton wrote:
I think your original plan is sound. 

1. Up the RF to 4. 
2. Add the node with auto_bootstrap true
3. Once bootrapping has finished the new node has all the data it needs. 
4. Check for secondary index creation using describe in the CLI to see which are build. You can also see progress using nodetool compactionstats

I'm a bit puzzled though, I just tried to increase R to 3 in a cluster with N=2. It serves reads and writes without issues CL.one. Is the described restriction is something that will be implemented in the future?
I had a quick glance at the code. IIRC there was an explicit check if RF > N, but I cannot find it any more. I'm guessing we now rely on a normal UnavailableFailure if there are not enough UP nodes. 

Cheers

-----------------
Aaron Morton
Freelance Developer
@aaronmorton

On 16/03/2012, at 8:56 PM, Mikael Wikblom wrote:

ok, thank you both for the clarification. So the correct approach would be to bootstrap the new node and run repair on each of the nodes in the cluster.

I'm a bit puzzled though, I just tried to increase R to 3 in a cluster with N=2. It serves reads and writes without issues CL.one. Is the described restriction is something that will be implemented in the future?

Thank you
Regards




On 03/16/2012 03:07 AM, aaron morton wrote:
The documentation is correct. 
I was mistakenly remembering discussions in the past about RF > #nodes. 

Cheers

-----------------
Aaron Morton
Freelance Developer
@aaronmorton

On 16/03/2012, at 4:34 AM, Doğan Çeçen wrote:

I'm not sure why this is not allowed. As long as I do not use CL.all there
will be enough nodes available to satisfy the read / write (at least when I
look at ReadCallback and the WriteResponseHandler). Or am I missing
something here?

According to http://www.datastax.com/docs/1.0/cluster_architecture/replication

"As a general rule, the replication factor should not exceed the
number of nodes in the cluster. However, it is possible to increase
replication factor, and then add the desired number of nodes
afterwards. When replication factor exceeds the number of nodes,
writes will be rejected, but reads will be served as long as the
desired consistency level can be met."

--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments



-- 
Mikael Wikblom
Software Architect
SiteVision AB
019-217058
mikael.wikblom@sitevision.se
http://www.sitevision.se



-- 
Mikael Wikblom
Software Architect
SiteVision AB
019-217058
mikael.wikblom@sitevision.se
http://www.sitevision.se
--------------000109010504000303060806--