Consider an Elasticsearch cluster with only one node configured as master-eligible but not data or ingest. What will the cluster.health API report for the number_of_data_nodes?
GET /_cluster/health
Master nodes do not hold data unless explicitly configured.
Master-eligible nodes manage cluster state but do not store data unless also configured as data nodes. Since this node is not a data node, number_of_data_nodes is 0.
Given a node configured only as an ingest node, what is the expected behavior when a document is sent to it for indexing?
PUT /my-index/_doc/1 { "field": "value" }
Ingest nodes handle preprocessing but do not store data.
Ingest nodes apply pipelines to documents and then forward them to data nodes for storage. They do not store data themselves.
In Elasticsearch, which node role primarily manages the cluster state and coordinates cluster-wide actions?
Think about which node decides the cluster's overall health and configuration.
Master-eligible nodes manage the cluster state, elect the master, and coordinate cluster-wide operations.
Assume a cluster with one master-eligible node and one data node. If the data node is down and you try to index a document, what error will Elasticsearch return?
PUT /my-index/_doc/1 { "field": "value" }
Think about shard availability on data nodes.
If the data node holding the primary shard is down, Elasticsearch cannot index the document and returns an unavailable_shards_exception.
Given a cluster with three nodes, all configured as node.data: true but node.master: false, why does the cluster fail to elect a master?
node1.yml: node.master: false node.data: true node2.yml: node.master: false node.data: true node3.yml: node.master: false node.data: true
Master election requires at least one master-eligible node.
All nodes have node.master: false, so none can become master. Without a master-eligible node, the cluster cannot elect a master.