主分片未激活或未分配是已知节点？

Question

我正在windows 8上运行弹性搜索4.1版。我试图通过java索引文档。运行JUNIT测试时，错误显示如下。

org.elasticsearch.action.UnavailableShardsException: [wms][3] Primary shard is not active or isn't assigned is a known node. Timeout: [1m], request: index {[wms][video][AUpdb-bMQ3rfSDgdctGY], source[{
    "fleetNumber": "45",
    "timestamp": "1245657888",
    "geoTag": "73.0012312,-123.00909",
    "videoName": "timestamp.mjpeg",
    "content": "ASD123124NMMM"
}]}
    at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction.retryBecauseUnavailable(TransportShardReplicationOperationAction.java:784)
    at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction.doStart(TransportShardReplicationOperationAction.java:402)
    at org.elasticsearch.action.support.replication.TransportShardReplicationOperationAction$AsyncShardOperationAction$3.onTimeout(TransportShardReplicationOperationAction.java:500)
    at org.elasticsearch.cluster.ClusterStateObserver$ObserverClusterStateListener.onTimeout(ClusterStateObserver.java:239)
    at org.elasticsearch.cluster.service.InternalClusterService$NotifyTimeout.run(InternalClusterService.java:497)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:722)

我不明白，为什么导致这个错误发生。当删除数据或索引时，它工作正常。可能的原因是什么。

Answer 1

在我的案例中，罪魁祸首是9300端口。它被封锁了。

Elasticsearch将绑定到HTTP和节点/传输API的单个端口。

它将首先尝试最低的可用端口，如果已经使用，请尝试下一个。如果您在机器上运行单个节点，它只会绑定到9200和9300。

所以我解封了9300端口，我可以走了。

在REDHAT linux中解锁端口。

sudo firewall-cmd --zone=public --add-port=9300/tcp --permanent
sudo firewall-cmd --reload
sudo iptables-save | grep 9300

Answer 2

问题：似乎elasticsearch停止发送数据到kibana，因为磁盘空间超出。您会得到org.elasticsearch.action.因为您的主分片不活动，所以会超时。为了加强理论-运行sudo df-h，您可能会从您机器中的/var/data中获得高百分比的数据量。

说明：根据关于elasticserach磁盘空间碎片分配的文档，Elasticsearch在决定是向该节点分配新碎片还是主动将碎片从该节点移开之前，会考虑该节点上的可用磁盘空间。为了覆盖默认磁盘空间碎片分配，需要设置4个变量

1 . cluster . routing . allocation . disk . threshold _ enabled默认为true。设置为false将禁用磁盘分配决策器。2 . cluster . routing . allocation . disk . watermark . low控制磁盘使用的低水位线。它默认为85%，这意味着Elasticsearch不会将碎片分配给磁盘使用率超过85%的节点。也可以将其设置为绝对字节值(如500mb ),以防止Elasticsearch在可用空间少于指定量时分配碎片。该设置对新创建的索引的主碎片没有影响，但会阻止分配它们的副本。

3.cluster.routing.allocation.disk.watermark。high控制高水位线。它默认为90%，这意味着Elasticsearch将尝试从磁盘使用率高于90%的节点重新定位碎片。还可以将其设置为绝对字节值（类似于低水位线），以便在节点的可用空间小于指定量时将碎片从节点重新定位。此设置会影响所有碎片的分配，无论以前是否分配。

4.cluster.routing.allocation.disk.watermark。flood_stage控制泛洪水位线。它默认为95%，这意味着Elasticsearch对每个索引强制执行一个只读索引块（index.blocks.read_only_allow_delete），该索引在至少有一个磁盘超过洪泛阶段的节点上分配了一个或多个碎片。这是防止节点耗尽磁盘空间的最后手段。一旦磁盘利用率低于高水位线，索引块将自动释放。

解决方案：现在让我们执行api调用，编辑配置，并增加磁盘空间分片分配限制（从90个默认值到95%-97%）：

 curl -XPUT -H 'Content-Type: application/json' 'localhost:9200/_cluster/settings' 
-d '{  "transient":{
 "cluster.routing.allocation.disk.watermark.low":"95%",
"cluster.routing.allocation.disk.watermark.high": "97%",
"cluster.routing.allocation.disk.watermark.flood_stage": "98%",
"cluster.info.update.interval": "1m"
}}'

Answer 3

你应该看看那个链接：http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/index-modules-allocation.html

特别是该部分：

cluster.routing.allocation.disk.watermark.low 控制磁盘使用情况的低水位线。它默认为 85%，这意味着一旦节点使用的磁盘超过 85%，ES 就不会将新分片分配给节点。它也可以设置为绝对字节值（如 500mb），以防止 ES 在可用空间量小于配置的空间量时分配分片。

cluster.routing.allocation.disk.watermark.high 控制高水位线。它默认为 90%，这意味着如果节点磁盘使用率超过 90%，ES 将尝试将分片重新定位到另一个节点。也可以将其设置为绝对字节值（类似于低水位线），以便在节点上可用的空间量小于配置的空间量时重新定位分片。