重启后为什么ElassticSearch不可用,某些分片未分配?

时间:2016-03-16 03:34:59

标签: java elasticsearch lucene centos

我在一个节点上运行了elasticsearch服务。我重新启动ES后。一些碎片保持未分配几分钟。

整个步骤如下:

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

  2. 我杀了我的弹性搜索过程

  3. 重启后,弹性搜索变为红色。有些碎片仍未分配。

  4. 我注意到的是。在我杀死弹性搜索之前,我检查了碎片,就像这样

    [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 
    

    看起来索引中的数据是重新平衡的。但我认为数据所在的位置是在索引时间内通过路由方法决定的。重新启动索引后为什么数据会重新平衡?

2 个答案:

答案 0 :(得分:1)

默认情况下,您创建的每个索引都有5 primary shardsone replica shard。如果您只有一个实例/一个弹性搜索节点正在运行,则所有primary shards都将分配给该节点,剩余的replica shards将处于unassigned状态。您可以通过运行另一个实例/节点来解决此问题。

根据documentation

  

unassigned_shards是群集状态中存在的分片,但在群集本身中找不到。未分配的分片的常见来源是未分配的副本。例如,具有五个分片和一个副本的索引将在单节点群集中具有五个未分配的副本。

答案 1 :(得分:1)

Baed on Val评论。

分片的大小不仅与文档的数量相关联,而且还与许多其他内容相关联,例如"删除"文档,doc值以及许多其他Lucene文件。 Lucene在启动期间做了一些家务管理

所以这是一个正常的启动过程

相关问题