incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mateusz Korniak <mateusz-li...@ant.gliwice.pl>
Subject Re: Bootstrapping a new node to a running cluster (setting RF > N)
Date Thu, 15 Mar 2012 10:24:04 GMT
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), add 
node (not responding to client reads), repair new node, turn on clients.

Would it be simpler than changing CL ?

> 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 you serve pages off the node.
> 
> 0. Personally I would run a repair before doing this to ensure the data is
> fully distributed. 1. Optionally, increase the CL  QUOURM. See step 3.
> 2. Add the new node with auto_bootstrap off. It will join the ring, write
> requests will be sent to it (from other cassandra nodes), but it should
> not get any direct client reads. It will not stream data from other nodes.
> 3. It is now possible for a READ to be received at an old node where it is
> no longer a replica for the row. It has to send the request to another
> node. If it is sent to the new node (at CL ONE) the read will fail. If you
> are running at a high CL it will always involve the old nodes. 4. Update
> the RF to 4. Every node is now a replica for every key.
> 5. Roll back the CL change.
> 6. Repair the new node.
> 7. Turn on the clients for the new node.

Regards,
-- 
Mateusz Korniak

Mime
View raw message