32879ec0d5
We introduce a new term in the glossary: RF-rack-valid keyspace. We also highlight in our user documentation that all keyspaces must remain RF-rack-valid throughout their lifetime, and failing to guarantee that may result in data inconsistencies or other issues. We base that information on our experience with materialized views in keyspaces using tablets, even though they remain an experimental feature. Along with the new term, we introduce a new configuration option called `rf_rack_valid_keyspaces`, which, when enabled, will enforce preserving all keyspaces RF-rack-valid. That functionality will be implemented in upcoming commits. For now, we materialize the restriction in form of a named requirement: a function verifying that the passed keyspace is RF-rack-valid. The option is disabled by default. That will change once we adjust the existing tests to the new semantics. Once that is done, the option will first be enabled by default, and then it will be removed. Fixes scylladb/scylladb#20356
29 lines
1.4 KiB
ReStructuredText
29 lines
1.4 KiB
ReStructuredText
=========================
|
|
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.
|