You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Micha <mi...@fantasymail.de> on 2017/07/13 15:22:59 UTC

adding nodes to a cluster and changing rf

Hi,

I want to extend my cluster (C* 3.9) from three nodes with RF 2  to
seven nodes with RF 3.

Is there a preferable way to do this?

For example:
setting "auto_bootstrap: true" and bootstrapping each new node at a time?

setting "auto_bootstrap: false" , starting all new nodes at once and
then "nodetool rebuild"?

Should I alter the RF after adding the new nodes?
I could add 2 nodes, then change the RF, then add the remaining 2 nodes.

Should all new nodes have "allocate_tokens_for_local_replication_factor"
set to 3 since the RF will be changed to 3 later?

There is quite some data stored, so I would prefer a method which does
fewer reorganisations of the data.


Thanks for your advice,
 Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
For additional commands, e-mail: user-help@cassandra.apache.org


Re: adding nodes to a cluster and changing rf

Posted by kurt greaves <ku...@instaclustr.com>.
Increasing RF will result in nodes that previously didn't have a replica of
the data now being responsible for it. This means that a repair is required
after increasing the RF.

Until the repair completes you will suffer from inconsistencies in data.
For example, in a 3 node cluster with RF 2, nodes A, B and C. A and B could
be responsible for the 2 replicas of row x. As soon as you increase the RF
to 3, C will also be responsible for x and thus can also answer queries
requesting x. But until row x is repaired and present on C, a request for x
against C will return no data.

If you are looking to increase RF on a live production system you should
perform a datacenter migration and increase the RF to 3 only on the new
datacenter, switching your clients across after rebuild+repair on the new
DC.

allocate_tokens_for_local_replication_factor is a DSE configuration
property. allocate_tokens_for_keyspace is the equivalent in Apache
Cassandra. This option is not related to RF changes so shouldn't be
necessary, however might not be a bad idea to research its usage if you are
planning on scaling to many nodes in the future.