ElasticSearch之分片及路由设置

Shard allocation is the process of allocating shards to nodes. This can happen during initial recovery, replica allocation, rebalancing, or when nodes are added or removed.

One of the main roles of the master is to decide which shards to allocate to which nodes, and when to move shards between nodes in order to rebalance the cluster.

replica – In the most recent versions (ES 7.x), by default, Elasticsearch creates 1 primary shard and 1 replica for each index. In the earlier versions, the default number of shards was 5 and the number of replicas was
1 per index.

The main difference between a primary and a replica shard is that only the primary shard can accept indexing requests. Both replica and primary shards can serve querying requests.

There are some important differences in how primary and replica shards behave. While both are capable of processing queries, indexing requests must first go through primary shards before they can be replicated to the replica shards. As noted above, if a primary shard becomes unavailable—for example, due to a node disconnection or hardware failure—a replica is promoted to take over its role.

While replicas can help in the case of a node failure, replicas use up memory and disk space, as do primary shards. They also use compute powers when indexing, so it is also important not to have too many. Another difference between the primary shards and replicas is that while the number of primary shards cannot be changed after the index has been created, the number of replicas can be altered at any time.

Another factor to consider with replicas is the number of nodes available. Replicas are always placed on different nodes from the primary shard, since two copies of the same data on the same node would add no protection if the node were to fail. As a result, for a system to support n replicas, there need to be at least n + 1 nodes in the cluster. For instance, if there are two nodes in a system and an index is configured with six replicas, only one replica will be allocated. On the other hand, a system with seven nodes is perfectly capable of handling one primary shard and six replicas.

Shards in Elastic Search- When we have a large number of documents, we may come to a point where a single node may not be enough—for example, because of RAM limitations, hard disk capacity, insufficient processing power, and inability to respond to client requests fast enough. In such a case, data can be divided into smaller parts called shards (where each shard is a separate Apache Lucene index). Each shard can be placed on a different server, and thus, your data can be spread among the cluster nodes. When you query an index that is built from multiple shards, Elasticsearch sends the query to each relevant shard and merges the result in such a way that your application doesn’t know about the shards. In addition to this, having multiple shards can speed up the indexing.

https://www.elastic.co/guide/en/elasticsearch/reference/7.9/modules-cluster.html#cluster-shard-allocation-settings
https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index
https://opster.com/elasticsearch-glossary/elasticsearch-replicas/
https://www.techartifact.com/blogs/2016/08/shards-and-replicas-in-elasticsearch.html
https://aws-labs.com/fix-elasticsearch-cluster-stuck-initializing-shards-mode/