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

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%,这意味着一旦使用超过85%的磁盘,ES将不会为节点分配新的分片.它也可以设置为绝对字节值(如500mb),以防止ES在小于配置的可用空间量时分配分片.

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

Answer 2

问题：由于磁盘空间超出，elasticsearch 似乎停止向 kibana 发送数据。org.elasticsearch.action.UnavailableShardsException由于您的主分片不活跃，因此您会超时。为了加强这个理论 - 运行一下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"
}}'