How To Configure a Tie-Breaker Node

The Aerospike Knowledge Base has moved to https://support.aerospike.com. Content on https://discuss.aerospike.com is being migrated to either https://support.aerospike.com or https://docs.aerospike.com. Maintenance on articles stored in this repository ceased on December 31st 2022 and this article may be stale. If you have any questions, please do not hesitate to raise a case via https://support.aerospike.com.

How To Configure a Tie-Breaker Node

Context

This article describes details about the configuration components of a tie-beaker node. Our blog on tie-breaker nodes for clusters using strong consistency explains how a permanently quiesced tie-breaker node works in a cluster with data across two racks.

Method

The important components of the tie-breaker node configuration are:

  1. Roster and Rack: Required. Include the tie-breaker node in the roster, and on its own rack.

  2. Basic configuration: Required. Include valid service and network stanzas like those of the other nodes. These stanzas allow the node to start up and join the cluster.

  3. Namespaces: Required. All namespaces configured on the other nodes with strong consistency must be configured on the tie-breaker node, and any unanimous parameter values must match with the namespace definitions on the other nodes. Non-unanimous parameters, such as storage-engine, may differ if the tie-breaker node is never expected to hold any data (but see Notes below).

  4. stay-quiesced: Set to true in the service stanza of the tie-breaker node, but not for any of the main nodes. This ensures the node does not become an active member of the cluster.

Notes

There is an important edge case to consider. If the cluster is very small, such that one rack plus the tie-breaker node does not add up to more nodes than the replication-factor (i.e., 1-node racks with RF=2, 2-node racks with RF=3), then the tie-breaker node will take writes when one rack goes out, whether or not it is quiesced. This is because a quiesced node is moved to the end of the succession list, not removed from it, so it is still eligible to take writes if the replication-factor is high enough. Furthermore, as a quiesced node will not drop its data, if you do end up in this situation, you will have to manually remove the data after the missing rack has been restored, migrations have completed, and the cluster is stable again.

  • If all strong consistency namespaces are configured data-in-memory on the tie-breaker node, then performing a cold restart of the tie-breaker node will be enough to clear out the data.
  • If any of the strong consistency namespaces are using persistent storage, you must add the configuration parameter cold-start-empty to the namespace stanzas of the node’s configuration parameter before performing a cold start.

Keywords

TIEBREAKER STRONG CONSISTENCY QUIESCE ROSTER STAY-QUIESCED ARBITER SC TENNIS

Timestamp

September 2021