Principles within an Elasticsearch cluster

    A running Elasticsearch instance is called a node, and a cluster consists of one or more nodes with the same cluster.name configuration, which share data and load pressure. When a node is added to or removed from the cluster, the cluster will redistribute all data evenly.

    When a node is elected as the master node, it will be responsible for managing all cluster-wide changes, such as adding or removing indexes, or adding or removing nodes. The master node does not need to be involved in operations such as document-level changes and searches, so when the cluster has only one master node, it will not become a bottleneck even if the traffic increases. Any node can become the master node.

    As a user, we can send requests to any node in the cluster, including the master node. Each node knows where any document is located and is able to forward our request directly to the node that stores the document we need. No matter which node we send the request to, it is responsible for collecting data back from each node containing the documents we need and returning the final result to the client. Elasticsearch manages all of this transparently.

 

Check the cluster health status:

#curl -X GET "localhost:9200/_cluster/health"

 

The return value status field indicates whether the current cluster is working properly in general:

Green: All primary and replica shards are up and running.

Yellow: All primary shards are functioning properly, but not all replica shards are functioning properly. Red: There are primary shards that are not functioning properly.
Adding an index: An index is actually a logical namespace that points to one or more physical shards. A shard is an underlying unit of work that holds only a portion of the total data. A shard is an instance of Lucene, and itself a full search engine. Our documents are stored and indexed into shards, but the application interacts directly with the index and not with the shards. Elasticsearch uses sharding to distribute data across the cluster. A shard can be a primary shard or a replica shard. Any document in the index belongs to a primary shard, so the number of primary shards determines the maximum amount of data the index can hold. Technically, a primary shard can store up to Integer.MAX_VALUE - 128 documents: a replica shard is just a copy of the primary shard. Replica shards act as redundant backups to protect against data loss in the event of a hardware failure, and serve read operations such as searching and returning documents. The number of replica shards can be modified at any time.

number_of_shards: the number of primary shards
number_of_replicas: replica shard format

 

Adding a second node: When a second node is started on the same machine, it will automatically discover the cluster and join it as long as it has the same cluster.name configuration as the first node. However, when starting nodes on different machines, in order to join the same cluster, you need to configure a list of unicast hosts that can be connected to.

discovery.zen.ping.unicast.hosts: ["host1", "host2:port”]