Re: Bootstrapping a new node to a running cluster

2012-03-16 Thread Mikael Wikblom
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

Re: Bootstrapping a new node to a running cluster

2012-03-16 Thread aaron morton
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 node

Re: Bootstrapping a new node to a running cluster

2012-03-16 Thread Mikael Wikblom
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 de

Re: Bootstrapping a new node to a running cluster

2012-03-15 Thread aaron morton
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 l

Re: Bootstrapping a new node to a running cluster

2012-03-15 Thread Doğan Çeçen
> 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_a

Re: Bootstrapping a new node to a running cluster

2012-03-15 Thread Mikael Wikblom
Hi Aaron, On 03/15/2012 10:52 AM, aaron morton wrote: 1. a running cluster of N=3, R=3 2. upgrade R to 4 You should not be allowed to set the RF higher than the number of nodes. 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 satisf

Re: Bootstrapping a new node to a running cluster (setting RF > N)

2012-03-15 Thread Mateusz Korniak
On Thursday 15 of March 2012, aaron morton wrote: > > 1. a running cluster of N=3, R=3 > > 2. upgrade R to 4 > > You should not be allowed to set the RF higher than the number of nodes. I wonder why is that restriction ? It would be easier to increase RF first (similar as having new node down),

Re: Bootstrapping a new node to a running cluster

2012-03-15 Thread aaron morton
> 1. a running cluster of N=3, R=3 > 2. upgrade R to 4 You should not be allowed to set the RF higher than the number of nodes. I'm going to assume that clients on the web server only talk to the local cassandra. So that when you add the new cassandra node it will not have any clients until yo

Bootstrapping a new node to a running cluster

2012-03-15 Thread Mikael Wikblom
Hi, I'm using cassandra (1.0.8) embedded in the same jvm as a webapplication. All data is available on all nodes (R = N), read / write CL.ONE. Is it correct to assume in the following scenario that the newly added node has all data locally and that secondary indexes are fully created afte