我在一个节点上运行了elasticsearch服务。我重新启动ES后。一些碎片保持未分配几分钟。
整个步骤如下:
我将大量数据加载到我的Elasticsearch中。
我杀了我的弹性搜索过程
重启后,弹性搜索变为红色。有些碎片仍未分配。
我注意到的是。在我杀死弹性搜索之前,我检查了碎片,就像这样
[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
看起来索引中的数据是重新平衡的。但我认为数据所在的位置是在索引时间内通过路由方法决定的。重新启动索引后为什么数据会重新平衡?
答案 0 :(得分:1)
默认情况下,您创建的每个索引都有5 primary shards
和one replica shard
。如果您只有一个实例/一个弹性搜索节点正在运行,则所有primary shards
都将分配给该节点,剩余的replica shards
将处于unassigned
状态。您可以通过运行另一个实例/节点来解决此问题。
unassigned_shards是群集状态中存在的分片,但在群集本身中找不到。未分配的分片的常见来源是未分配的副本。例如,具有五个分片和一个副本的索引将在单节点群集中具有五个未分配的副本。
答案 1 :(得分:1)
Baed on Val评论。
分片的大小不仅与文档的数量相关联,而且还与许多其他内容相关联,例如"删除"文档,doc值以及许多其他Lucene文件。 Lucene在启动期间做了一些家务管理
所以这是一个正常的启动过程