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

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

特别是那部分：

cluster.routing.allocation.disk.watermark.low控制低位   磁盘使用的水印。它默认为85％，这意味着ES不会   一旦用户拥有超过85％的磁盘，就会为节点分配新的分片。   它也可以设置为绝对字节值（如500mb）来防止   ES，如果小于配置的空间量，则分配分片   是可用的。

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

Answer 2

在我的情况下，罪魁祸首是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 3

问题：似乎随着磁盘空间被超出，elasticsearch停止向kibana发送数据。根据您的 主分片未激活 的事实，您得到org.elasticsearch.action.UnavailableShardsException并超时。为了加强理论，请运行sudo df -h，您可能会从计算机中的/var/data获得高百分比的数据量。

说明：根据documentation on elasticserach disk space shard allocation，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 4

我遇到了完全相同的错误，在我的情况下，我有多个主节点和数据节点。主节点已添加到负载均衡器，但数据节点未添加。因此master无法与数据节点进行通信。

将所有数据节点都放入负载均衡器后，我的问题就解决了。

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

4 个答案: