主分片未处于活动状态或未分配是已知节点？

java indexing elasticsearch sharding

2022-09-02 12:46:01

我在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)

我无法弄清楚，为什么会导致此错误发生。当删除数据或索引时，它工作正常。可能的原因是什么。

答案 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 将尝试将分片重新定位到另一个节点。它还可以设置为绝对字节值（类似于低水位线），以便在节点上可用空间小于配置的可用空间量时重新定位分片。

答案 2

问题：似乎 elasticsearch 会在磁盘空间超出时停止向 kibana 发送数据。您获得和超时是基于您的主分片未处于活动状态的事实。为了加强理论 - 运行，您可能会从计算机中获得高百分比的数据量。org.elasticsearch.action.UnavailableShardsExceptionsudo 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"
}}'