Easysearch implements an adaptive quorum system that dynamically recalculates the voting majority whenever the cluster topology changes. This mechanism ensures that leadership elections and state updates remain resilient by automatically identifying the active set of Master-eligible instances during any configuration shift.
When planning to decommission Master-eligible instances, administrators must strictly adhere to the majority quorum rule. Shutting down fifty percent or more of these voting-capable nodes simultaneously will trigger a clluster-wide unavailability state. To prevent quorum loss, decommissioning should be performed incrementally. Removing a single instance at a time allows the cluster’s coordination layer to stabilize and recompute the voting majority safely.
Consider a cluster initialized with five voting-capable nodes. Following the incremental approach, the cluster will eventually reach a state with only two active voting nodes. At this stage, standard removal procedures cannot be applied to either remaining instance, as terminating one would drop the active count to exactly fifty percent, causing the cluster to lose quorum.
To proceed beyond this threshold, you must manually intervene in the voting configuration by explicitly excluding the target node from the voting majority before initiating shutdown. Once the node is successfully decoupled from the quorum calculation, it can be safely terminated without risking cluster availability.
Inspecting Current Quorum Configuration
Before making modifications, verify the active voting set using the cluster state endpoint:
curl -X GET "http://localhost:9200/_cluster/state?filter_path=metadata.cluster_coordination.last_committed_config" -H "Content-Type: application/json"
The response will list the nodes currently participating in elections. Note that if a node has already gone offline, the dynamic coordinator may retain it in the committed configuration to preserve an odd-numbered voting majority, preventing premature quorum adjustments.
Applying Voting Exclusions
When preparing to decommission a specific instance (e.g., elastic-master-03), add it to the temporary exclusion list:
curl -X POST "http://localhost:9200/_cluster/voting_config_exclusions?node_names=elastic-master-03" -H "Content-Type: application/json"
This operation immediately removes the specified node from future election calculations. Concurrently, the cluster’s coordinator will automaticlaly purge any stale or offline nodes from the voting set to maintain a valid majority.
Clearing Exclusion Lists and Bulk Operations
After the targeted instance is safely shut down, clear the exclusion cache to free up configuration memory. An empty exclusion list is the expected baseline for a healthy cluster:
curl -X DELETE "http://localhost:9200/_cluster/voting_config_exclusions?wait_for_removal=true" -H "Content-Type: application/json"
The exclusion API also supports bulk decommissioning. By registering multiple Master-eligible nodes in the exclusion list simultaneously, you can trigger an automatic quorum recalculation that safely isolates them. For instance, shrinking a five-node cluster down to a single survivor requires listing four nodes in the exclusion payload. Once the API acknowledges the request, those four instances can be terminated concurrently without triggering a split-brain or quorum loss scenario.