Class Reconfigurator
java.lang.Object
org.elasticsearch.cluster.coordination.Reconfigurator
Computes the optimal configuration of voting nodes in the cluster.
-
Field Summary
Modifier and TypeFieldDescriptionThe cluster usually requires a vote from at least half of the master nodes in order to commit a cluster state update, and to achieve the best resilience it makes automatic adjustments to the voting configuration as master nodes join or leave the cluster. -
Constructor Summary
-
Method Summary
Modifier and TypeMethodDescriptionreconfigure(Set<DiscoveryNode> liveNodes, Set<String> retiredNodeIds, DiscoveryNode currentMaster, CoordinationMetadata.VotingConfiguration currentConfig)
Compute an optimal configuration for the cluster.void
setAutoShrinkVotingConfiguration(boolean autoShrinkVotingConfiguration)
toString()
-
Field Details
-
CLUSTER_AUTO_SHRINK_VOTING_CONFIGURATION
The cluster usually requires a vote from at least half of the master nodes in order to commit a cluster state update, and to achieve the best resilience it makes automatic adjustments to the voting configuration as master nodes join or leave the cluster. Adjustments that fix or increase the size of the voting configuration are always a good idea, but the wisdom of reducing the voting configuration size is less clear. For instance, automatically reducing the voting configuration down to a single node means the cluster requires this node to operate, which is not resilient: if it broke we could restore every other master-eligible node in the cluster to health and still the cluster would be unavailable. However not reducing the voting configuration size can also hamper resilience: in a five-node cluster we could lose two nodes and by reducing the voting configuration to the remaining three nodes we could tolerate the loss of a further node before failing. We offer two options: either we auto-shrink the voting configuration as long as it contains more than three nodes, or we don't and we require the user to control the voting configuration manually using the retirement API. The former, default, option, guarantees that as long as there have been at least three master-eligible nodes in the cluster and no more than one of them is currently unavailable, then the cluster will still operate, which is what almost everyone wants. Manual control is for users who want different guarantees.
-
-
Constructor Details
-
Reconfigurator
-
-
Method Details
-
setAutoShrinkVotingConfiguration
public void setAutoShrinkVotingConfiguration(boolean autoShrinkVotingConfiguration) -
toString
-
reconfigure
public CoordinationMetadata.VotingConfiguration reconfigure(Set<DiscoveryNode> liveNodes, Set<String> retiredNodeIds, DiscoveryNode currentMaster, CoordinationMetadata.VotingConfiguration currentConfig)Compute an optimal configuration for the cluster.- Parameters:
liveNodes
- The live nodes in the cluster. The optimal configuration prefers live nodes over non-live nodes as far as possible.retiredNodeIds
- Nodes that are leaving the cluster and which should not appear in the configuration if possible. Nodes that are retired and not in the current configuration will never appear in the resulting configuration; this is useful for shifting the vote in a 2-node cluster so one of the nodes can be restarted without harming availability.currentMaster
- The current master. Unless retired, we prefer to keep the current master in the config.currentConfig
- The current configuration. As far as possible, we prefer to keep the current config as-is.- Returns:
- An optimal configuration, or leave the current configuration unchanged if the optimal configuration has no live quorum.
-