java - 为什么 ElasticSearch 重启后不可用，部分分片未分配？

Question

我有一个在一个节点上运行的 Elasticsearch 服务。重启ES后。一些分片在几分钟内保持未分配状态。

整个步骤如下:

1. 我将大量数据加载到我的 Elasticsearch 中。

2. 我终止了我的 elasticsearch 进程

3. 重启后elasticsearch变成红色。一些碎片仍未分配。

我注意到的是。在杀掉elasticsearch之前，我查看了shard，是这样的

[sflow@ES01 bin]$ curl 'localhost:9200/_cat/shards?v'
index             shard prirep state      docs store ip            node 
sflow_51452355200 2     p      STARTED 5997062 2.8gb 10.79.148.184 ES01 
sflow_51452355200 1     p      STARTED 6000474 2.9gb 10.79.148.184 ES01 
sflow_51452355200 4     p      STARTED 5997701 3.1gb 10.79.148.184 ES01 
sflow_51452355200 3     p      STARTED 5999565   3gb 10.79.148.184 ES01 
sflow_51452355200 0     p      STARTED 5999198 2.8gb 10.79.148.184 ES01 

每个分片的大小是不平衡的。

重启后分片会像下面这样一段时间

[sflow@ES01 bin]$ curl 'localhost:9200/_cat/shards?v'
index             shard prirep state        docs store ip            node 
sflow_51452355200 4     p      INITIALIZING            10.79.148.184 ES01 
sflow_51452355200 2     p      INITIALIZING            10.79.148.184 ES01 
sflow_51452355200 3     p      UNASSIGNED                                 
sflow_51452355200 1     p      INITIALIZING            10.79.148.184 ES01 
sflow_51452355200 0     p      INITIALIZING            10.79.148.184 ES01 

几分钟后，碎片变成了下面

[sflow@ES01 bin]$ curl 'localhost:9200/_cat/shards?v'
index             shard prirep state      docs store ip            node 
sflow_51452355200 4     p      STARTED 5997701 2.3gb 10.79.148.184 ES01 
sflow_51452355200 2     p      STARTED 5997062 2.3gb 10.79.148.184 ES01 
sflow_51452355200 3     p      STARTED 5999565 2.3gb 10.79.148.184 ES01 
sflow_51452355200 1     p      STARTED 6000474 2.3gb 10.79.148.184 ES01 
sflow_51452355200 0     p      STARTED 5999198 2.3gb 10.79.148.184 ES01 

索引中的数据似乎已重新平衡。但我认为数据应该位于的位置是在索引时间内由路由方法决定的。为什么我重新启动索引后数据会重新平衡？

Answer 1

默认情况下，您创建的每个索引都有 5 个主分片 和 一个副本分片。如果你只有一个 Elasticsearch 实例/一个节点在运行，所有的primary shards将被分配给那个节点，剩余的replica shards将处于unassigned状态。您可以通过运行另一个实例/节点来克服这个问题。

根据documentation :

unassigned_shards are shards that exist in the cluster state, but cannot be found in the cluster itself. A common source of unassigned shards are unassigned replicas. For example, an index with five shards and one replica will have five unassigned replicas in a single-node cluster.