Change the Default Replication Factor

DataStax Mission Control is currently in Public Preview. DataStax Mission Control is not intended for production use, has not been certified for production workloads, and might contain bugs and other functional issues. There is no guarantee that DataStax Mission Control will ever become generally available. DataStax Mission Control is provided on an “AS IS” basis, without warranty or indemnity of any kind.

If you are interested in trying out DataStax Mission Control please join the Public Preview.

To create a cluster with a replication factor (RF) that varies from the default of 3, follow this procedure. It guides you through adjusting the allocate_tokens_for_local_replication_factor setting in the MissionControlCluster manifest. DataStax Mission Control does not recompute the token ranges and change tokens when modifying an existing cluster.

Procedure

This example involves a 10-node datacenter and the need to create a DSE cluster with a RF of 5.

Review the sample MissionControlCluster manifest:
```
apiVersion: missioncontrol.datastax.com/v1beta1
kind: MissionControlCluster
metadata:
  name: demo
spec:
  k8ssandra:
    cassandra:
      serverVersion: 6.8.25
      config:
        cassandraYaml:
          num_tokens: 1
          allocate_tokens_for_local_replication_factor: 5
      datacenters:
        - metadata:
            name: dc1
          size: 10
```
Datacenter dc1 is defined with 10 nodes. The allocate_tokens_for_local_replication_factor setting specifies a replication factor of 5, overriding the DataStax Mission Control default setting of 3. When you create a cluster, DataStax Mission Control computes and assigns tokens for the first 5 nodes in the cluster, leaving the remaining 5 nodes to determine their best tokens. DataStax Mission Control does not recompute token ranges or modify tokens for existing clusters.

Review the DSE Cluster token ring details with this command run from a node in a pod:

kubectl exec demo-dc1-rack1-sts-0 -c cassandra -- nodetool -u demo-superuser -pw <omitted> ring ks1

The keyspace ks1 is the last parameter, avoiding the resulting Owns column from displaying incongruous data.

Sample output:

Datacenter: dc1
==========
Address       Rack     Status State   Load       Owns    Token
                                                         8301034833169298226
10.100.18.24  default  Up     Normal  78.88 KiB  50.00%  -9223372036854775808
10.100.22.6   default  Up     Normal  78.89 KiB  60.00%  -5534023222112865485
10.100.6.16   default  Up     Normal  68.74 KiB  50.00%  -3689348814741910324
10.100.20.9   default  Up     Normal  73.65 KiB  50.00%  -1844674407370955162
10.100.10.20  default  Up     Normal  68.74 KiB  50.00%  -922337203685477582
10.100.0.17   default  Up     Normal  68.72 KiB  50.00%  -1
10.100.19.6   default  Up     Normal  73.65 KiB  40.00%  1844674407370955161
10.100.8.16   default  Up     Normal  73.65 KiB  50.00%  5534023222112865484
10.100.23.6   default  Up     Normal  73.65 KiB  50.00%  7378697629483820645
10.100.5.19   default  Up     Normal  73.89 KiB  50.00%  8301034833169298226

The Owns column indicates that each node holds between 40% and 60% of the data. While not ideal this is still acceptable because the expected ownership for each node is calculated at 50% = 5 * 1/10. That is the RF multiplied by the num_tokens/node.

What’s next?

Rebalance an existing cluster. Assign tokens to new nodes that are joining an existing cluster.