What do the master, data, ingest, and coordinating-only node roles do in an Elasticsearch cluster?

## How roles are declared Each node lists its jobs in `elasticsearch.yml`: ``` node.roles: [ master ] ``` A node with no `node.roles` setting takes on most roles at once, which is why a default single-node install just works. An explicitly **empty** list is meaningful and is the only way to express "coordinating-only". ## Master-eligible nodes Master-eligible nodes are the candidates for election. Exactly one of them is the elected master at any time, and it owns the *cluster state*: the list of indices, their settings and mappings, which node holds each shard, node membership, index templates, and ILM policies. Every cluster-state change — creating an index, updating a mapping, allocating or relocating a shard, a node joining or leaving — is published by the master to all nodes. The master does **not** route search or indexing traffic, so its CPU need is modest; what it needs is stable memory and, above all, not to be starved of CPU or blocked by long GC pauses on a node that is also serving heavy queries. That is the whole argument for dedicated masters: a data node under a heavy aggregation load can be slow to respond to the master's publications, and the price is election churn or a stalled cluster state. The standard highly available shape is **three dedicated master-eligible nodes**. Three is not arbitrary: election requires a strict majority of the voting configuration, and three tolerates the loss of one. Adding a fourth buys nothing extra in fault tolerance. ## Data nodes and data tiers Data nodes hold the shards and do the real work: they build segments during indexing, execute the query and fetch phases, and compute aggregation buckets. They need heap, fast disk and CPU. In current versions the data role is split into tier roles (`data_content`, `data_hot`, `data_warm`, `data_cold`, `data_frozen`) so that indices can be steered onto hardware that matches their age and access pattern; a plain `data` role makes a node eligible for all tiers. The generic `data` role is still perfectly valid for a small uniform cluster. ## Ingest nodes An ingest node can execute an *ingest pipeline* — a chain of processors (grok, date parsing, enrichment, field renaming, drop) applied to a document before it is indexed. Any node with the `ingest` role can run one, and the coordinating node forwards documents to an ingest node when the target index or the bulk request names a pipeline. Heavy pipelines — regular-expression parsing of log lines is the classic case — burn CPU, which is the reason to give them their own nodes when ingestion volume is large. ## Coordinating-only nodes Every node coordinates: whichever node receives a client request becomes the coordinating node for it, fans the query out to one copy of each relevant shard, collects per-shard results, merges and sorts them, then fetches the documents for the final hits. A **coordinating-only** node (`node.roles: []`) does only that. It needs heap for merging and CPU for sorting, but no disk for shards. Teams add them as a smart load-balancing tier in front of the cluster, especially when queries return large result sets or heavy aggregations whose reduce step would otherwise consume heap on a data node. The tradeoff is a genuine one: a coordinating-only node adds a network hop and can itself become a memory bottleneck if it merges enormous responses, so they are worth it at scale and pointless on a three-node cluster. ## The remaining roles `ml` runs machine-learning jobs and model inference. `transform` runs transform jobs that pivot indices. `remote_cluster_client` allows a node to connect to remote clusters for cross-cluster search or replication — worth remembering because a node that must reach remote clusters needs this role explicitly once you start listing roles by hand. `voting_only` combines with `master` to produce a node that votes in elections but can never be elected — a cheap tiebreaker. ## Why separate roles at all On a small cluster, do not. Three nodes each holding every role is a perfectly good design and simpler to operate. Role separation earns its keep when the cluster is big enough that one workload can starve another: dedicated masters so cluster-state work is never blocked by a runaway query, dedicated ingest so a CPU-hungry pipeline does not slow search, dedicated coordinating nodes so a large aggregation reduce does not evict a data node's page cache or blow its heap. Every dedicated node is also a machine you pay for and monitor, so the reason to add one should always be a specific resource you are protecting.