========================= Zero-token Nodes

By default, all nodes in a cluster own a set of token ranges and are used to replicate data. In certain circumstances, you may choose to add a node that doesn't own any token. Such nodes are referred to as zero-token nodes. They do not have a copy of the data but only participate in Raft quorum voting.

To configure a zero-token node, set the join_ring parameter to false.

You can use zero-token nodes in multi-DC deployments to reduce the risk of losing a quorum of nodes. See :doc:Preventing Quorum Loss in Symmetrical Multi-DC Clusters </operating-scylla/procedures/cluster-management/arbiter-dc> for details.

Note that:

• Zero-token nodes are ignored by drivers, so there is no need to change the load balancing policy on the clients after adding zero-token nodes to the cluster.
• Zero-token nodes never store replicated data, so running nodetool rebuild, nodetool repair, and nodetool cleanup can be skipped as it does not affect zero-token nodes.
• Racks consisting solely of zero-token nodes are not taken into consideration when deciding whether a keyspace is :term:RF-rack-valid <RF-rack-valid keyspace>. However, an RF-rack-valid keyspace must have the replication factor equal to 0 in an :doc:arbiter DC </operating-scylla/procedures/cluster-management/arbiter-dc>. Otherwise, it is RF-rack-invalid.