A single-node cluster is an Elasticsearch cluster formed by one running node. Starting Elasticsearch for the first time creates this arrangement, making it a practical place to learn, test searches, and try a product on a personal machine. section 14.1.1 section 3.2.5
One node can host an index’s primary shards, but it cannot host replicas of shards it already holds. A replica on the same node would not protect against that node or machine failing, so Elasticsearch leaves that replica unassigned. An index configured with replicas can therefore leave a one-node cluster in an unhealthy YELLOW state rather than fully healthy. section 14.1.1 section 3.2.5
Create an index with a primary shard and a replica
For a chats index with one primary shard and one replica, create the index with both settings. On a single node, the primary shard is created, while the replica remains unassigned because Elasticsearch will not place both copies on one node. This is useful for seeing the difference between an index’s requested replica count and the copies that can actually be allocated. section 14.1.1
Listing 14.1 Creating the chats index
PUT chats
{
"settings": {
"number_of_shards": 1,
"number_of_replicas": 1
}
}
This request defines one primary shard and one replica for chats; the replica needs a second eligible node before it can be allocated. section 14.1.1
Use a single-node cluster with these operational limits in mind:
- Treat it as a development or learning setup, not a production-grade resilience design. section 14.1.1 section 3.2.5
- Avoid treating multiple nodes on one machine as fault tolerance: a machine crash affects every node there, and replica placement still avoids the machine holding the primary. section 14.1.1 section 3.2.5
- Use a dedicated server rather than bundling Elasticsearch with resource-hungry applications when deploying a node. section 14.1.1
- Check cluster health and shard allocation when a replica is unassigned; the allocation explanation identifies why Elasticsearch cannot place it. section 14.1.1
To grow beyond one node, start additional Elasticsearch nodes with the same cluster.name. The new nodes join the existing cluster, and Elasticsearch distributes shards and replicas as nodes are added or removed. A replica on a second node can protect availability: if one node fails, its replica can be promoted and the cluster can continue as a single-node cluster until another node returns. section 14.1.2 section 3.2.5
Adding nodes is also a capacity decision. Nodes can be added to increase read throughput or indexing performance, while resources or nodes can be removed when demand declines. Forecasting data and workload needs helps determine when a development-sized cluster must become a larger deployment. section 14.1
