Adding vnodes to an existing cluster

Virtual nodes (vnodes) greatly simplify adding nodes to an existing cluster:

Calculating tokens and assigning them to each node is no longer required.
Rebalancing the nodes within a datacenter is no longer necessary because a node joining the datacenter assumes responsibility for an even portion of the data.

For a detailed explanation about how vnodes work, see Data distribution.

If you do not use vnodes, see Adding single-token nodes to a cluster.

When adding multiple nodes to the cluster using the allocation algorithm, ensure that nodes are added one at a time. If nodes are added concurrently, the algorithm assigns the same tokens to different nodes.

Configuration file locations

The location of the cassandra-rackdc.properties depends on the type of installation:

Package installations and Installer-Services installations: /etc/dse/cassandra/cassandra-rackdc.properties
Tarball installations and Installer-No Services: installation_location/resources/cassandra/conf/cassandra-rackdc.properties

The location of the cassandra.yaml file depends on the type of installation:

Package installations and Installer-Services installations: /etc/dse/cassandra/cassandra.yaml
Tarball installations and Installer-No Services installations: <installation_location>/resources/cassandra/conf/cassandra.yaml

The location of the cassandra-topology.properties file depends on the type of installation:

Package installations and Installer-Services installations: /etc/dse/cassandra/cassandra-topology.properties
Tarball installations and Installer-No Services installations: <installation_location>/resources/cassandra/conf/cassandra-topology.properties

Procedure

Install DSE on the new nodes, but don’t start DSE.

If DSE starts automatically, stop the node and clear the data.

You must install and configure the same version (major, minor, and patch) of DSE on all nodes in the cluster before you start any of the nodes.

Copy the snitch properties file from another node in the same center datacenter to the node you are adding.
- cassandra-topology.properties file is used by the PropertyFileSnitch. Add an entry for the new node, IP_address=dc_name:rack_name
- cassandra-rackdc.properties file is used by the GossipingPropertyFileSnitch, Ec2Snitch, Ec2MultiRegionSnitch, and GoogleCloudSnitch adjust the rack number if required.

Set the following properties in the cassandra.yaml file:

Dynamically allocating tokens based on the keyspace replication factors in the datacenter:
```
auto_bootstrap: true
cluster_name: 'cluster_name'
listen_address:
endpoint_snitch: snitch_name
num_tokens: 8
allocate_tokens_for_local_replication_factor: RF_number
seed_provider:
    - class_name: seedprovider_name
      parameters:
      - seeds: "IP_address_list"
```
For RF_number if the keyspaces in the datacenter have different replication factors (RF), use the factor of the most data intensive keyspace, or when multiple keyspaces with equal data intensity exist, use the highest RF When adding multiple nodes alternate between the different RF.

Randomly assign tokens:

auto_bootstrap: true
cluster_name: 'cluster_name'
listen_address:
endpoint_snitch: snitch_name
num_tokens: 128
seed_provider:
    - class_name: seedprovider_name
      parameters:
          - seeds: "IP_address_list"

Manually add the auto_bootstrap setting if it does not exist in the cassandra.yaml. The other settings should exist in the default cassandra.yaml file, ensure that you uncomment and set.

Don’t make every node a seed node because it increases maintenance and reduces gossip performance. Gossip optimization isn’t critical, but DataStax recommends a small seed list with two or three seed nodes per datacenter.

Change any other non-default settings you have made to your existing cluster in the cassandra.yaml file and cassandra-topology.properties or cassandra-rackdc.properties files. Use the diff command to find and merge any differences between existing and new nodes.
Start the new node to begin the bootstrapping process.
Verify that the node is fully bootstrapped using nodetool status. All other nodes must be up (UN) and not in any other state.
After all new nodes are running, run nodetool cleanup on each of the previously existing nodes to remove the keys that no longer belong to those nodes. Wait for cleanup to complete on one node before running nodetool cleanup on the next node.

Failure to run nodetool cleanup after adding a node may result in data inconsistencies including resurrection of previously deleted data.

Adding vnodes to an existing cluster

Configuration file locations

Procedure

Was this helpful?

Give Feedback