POST/_cluster/reroute?retry_failed=true retry_failed(可选,布尔值)如果为true,则重试由于后续分配失败过多而阻塞的分片的分配。 场景4:由于节点频繁离线导致集群健康状态变化 异常日志多为以下内容: 代码语言:javascript 复制 node-left[{bbs-tagdata-es-prd-050201-cvm}{ImUkdwUSRougiS8jdGlh3A}{IuYyXPRWQIa...
,"node_decision":"no","store":{"found":false}]} 解决方案 方案一:重试分配上线失败的分片 这是一种乐观的场景,这种情况通常是由于集群压力大,导致的分片无法分配,这里我们尝试重新分配: 代码语言:json 复制 [root@sh ~]# curl -s -XPOST localhost:9200/_cluster/reroute?retry_failed=true{"acknowledged...
retry_failed=true可以解决问题,如果按照你说的依然无法解决,可能还有其他原因导致锁住该shard的线程长时间操作该shard无法释放锁(长时间GC?)。 如果retry_failed无法解决问题,可以尝试一下allocate_stale_primary,前提是需要知道这个shard的primary在哪个结点上。实在解决不了,又不想丢数据,还可以重启一下该结点,内存锁...
其实整个问题处理过程中还有一些其它的细节在文中没有提到,集群在默认开启自动shard均衡过程中由于shard多次尝试分配无法成功,达到默认的5次重试之后就会报错,这个时候其实可以尝试将集群的自动分片关闭"cluster.routing.allocation.enable": "none",然后执行"POST /_cluster/reroute?retry_failed=true"来重置计数,最后通过...
POST /_cluster/reroute?retry_failed=true 主日志中出现SSL/TSL相关报错如何处理? 报错原因 如果主日志中出现如下图报错,表示SSL连接中传入了明文流量。这通常发生在未使用加密通信的节点尝试连接到使用加密通信的节点时。 解决方案 建议您按照以下方式排查: ...
原因是:shard 自动分配 已经达到最大重试次数5次,仍然失败了,所以导致"shard的分配状态已经是:no_attempt"。这时在Kibana Dev Tools,执行命令:POST /_cluster/reroute?retry_failed=true即可。由index.allocation.max_retries参数来控制最大重试次数。 The cluster will attempt to allocate a shard a maximum of in...
POST /_cluster/reroute?dry_run=false&explain=true&retry_failed=false 另外针对节点10.15.220.165 上分片较多,先计算平衡时的分片数: app-es 为 410 个分片,1副本,6个节点,则平均为 410*2/6=136,设置为 136+6=142 PUT clue-online-*/_settings ...
retry_failed=true命令,重新分配分片。 缓存导致资源占用。 建议使用POST /<索引名>/_cache/clear?fielddata=true命令清理缓存。 在进行升配等集群变更操作。 建议中断当前变更,在升配页面选择强制变更,具体操作请参见升配集群。 实例规格较低资源不足,例如1核2 GiB、2核4 GiB等规格。 建议升配集群,具体操作请...
curl -u elastic:'password' -XPOST 'http://192.168.2.131:9200/_cluster/reroute?retry_failed=true' 1. 分片分配设置 cluster.routing.allocation.enable参数为 null时,允许进行分片分配;该参数为primaries时,仅允许分配主分片的分片;该参数为none时,禁用所有分片分配,如下所示: ...
如果retry_failed无法解决问题,可以尝试一下allocate_stale_primary,前提是需要知道这个shard的primary在哪个结点上。实在解决不了,又不想丢数据,还可以重启一下该结点,内存锁应该可以释放。 执行集群reroute命令: curl -XPOST "http://ip:9200/_cluster/reroute?retry_failed=true" ...