# 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 [Preventing Quorum Loss in Symmetrical Multi-DC Clusters](https://docs.scylladb.com/manual/master/operating-scylla/procedures/cluster-management/arbiter-dc.md) 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 [RF-rack-valid](https://docs.scylladb.com/manual/master/reference/glossary.md#term-RF-rack-valid-keyspace).
  However, an RF-rack-valid keyspace must have the replication factor equal to 0
  in an [arbiter DC](https://docs.scylladb.com/manual/master/operating-scylla/procedures/cluster-management/arbiter-dc.md).
  Otherwise, it is RF-rack-invalid.