How to configure coordinating-only nodes in Elasticsearch

Dedicated coordinating-only nodes provide an entry point for client traffic while keeping data and master nodes focused on shard work and cluster state operations, reducing contention during heavy search and bulk indexing workloads.

In Elasticsearch, any node that receives a request can act as a coordinator by fanning out searches to shard copies, gathering partial results, performing the reduce phase, and returning the final response. Assigning an empty node.roles list removes master, data, ingest, and other specialist responsibilities while keeping the node in the cluster to route and merge requests.

Coordinating-only nodes still require CPU and heap for request queuing, result reduction, and large aggregations, so undersizing can shift bottlenecks instead of removing them. Repurposing an existing node that previously held shard data may require draining shards and cleaning the data path before the service can start with the new role set. Secured clusters using TLS and authentication require matching client options for the verification commands.

1. Open /etc/elasticsearch/elasticsearch.yml in an editor with sudo privileges.

   $ sudoedit /etc/elasticsearch/elasticsearch.yml

2. Set node.roles to an empty list.

   node.roles: [ ]

   Changing roles on a node that previously stored shards can prevent startup until the data path is repurposed or cleaned.

3. Restart the Elasticsearch service to apply the updated role settings.

   $ sudo systemctl restart elasticsearch

   Coordinating-only nodes often need additional heap for large aggregations and high-concurrency searches. Keep Xms and Xmx equal when manual heap sizing is configured.

   Related: How to manage the Elasticsearch service with systemctl in Linux

4. Verify the local node reports no roles through the Nodes API.

   $ curl -s "http://localhost:9200/_nodes/_local?filter_path=nodes.*.name,nodes.*.roles&pretty"
   {
     "nodes" : {
       "T8kqD3wqQ_2k2XkLz9P9AQ" : {
         "name" : "es-coord-1",
         "roles" : [ ]
       }
     }
   }

   Clusters with TLS and authentication enabled typically require an https://localhost:9200 endpoint plus curl options such as --cacert and --user.

5. Confirm the node can serve cluster requests from the coordinating endpoint.

   $ curl -s "http://localhost:9200/_cluster/health?pretty"
   {
     "cluster_name" : "es-prod",
     "status" : "green",
     "timed_out" : false,
     "number_of_nodes" : 5,
     "number_of_data_nodes" : 3,
     "active_primary_shards" : 42,
     "active_shards" : 84,
     "relocating_shards" : 0,
     "initializing_shards" : 0,
     "unassigned_shards" : 0,
     "delayed_unassigned_shards" : 0,
     "number_of_pending_tasks" : 0,
     "number_of_in_flight_fetch" : 0,
     "task_max_waiting_in_queue_millis" : 0,
     "active_shards_percent_as_number" : 100.0
   }

   A yellow status can be normal when replica shards are still allocating.