POST/_cluster/reroute?retry_failed=true retry_failed(可选,布尔值)如果为true,则重试由于后续分配失败过多而阻塞的分片的分配。 场景4:由于节点频繁离线导致集群健康状态变化 异常日志多为以下内容: 代码语言:javascript 复制 node-left[{bbs-tagdata-es-prd-050201-cvm}{ImUkdwUSRougiS8jdGlh3A}{IuYyXPRWQIa...
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"来重置计数,最后通过...
,"node_decision":"no","store":{"found":false}]} 解决方案 方案一:重试分配上线失败的分片 这是一种乐观的场景,这种情况通常是由于集群压力大,导致的分片无法分配,这里我们尝试重新分配: 代码语言:json 复制 [root@sh ~]# curl -s -XPOST localhost:9200/_cluster/reroute?retry_failed=true{"acknowledged...
curl-XPOST"http://ip:9200/_cluster/reroute?retry_failed=true" 再看分片状态: 此时集群已经恢复Green。大功告成。 总结 一、遇到集群Red时,我们可以从如下方法排查: 集群层面:/_cluster/health。 索引层面:/_cluster/health?pretty&level=indices。
curl -XPOST localhost:9200/_cluster/reroute?retry_failed=false 5.3、检查集群设置和索引设置看看是否设置问题导致分片不能分配 curlhttp://172.16.106.63:9200/_cluster/settings?pretty curlhttp://172.16.106.63:9200/event_20190313/_settings?pretty
POST /_cluster/reroute?retry_failed=true 主日志中出现SSL/TSL相关报错如何处理? 报错原因 如果主日志中出现如下图报错,表示SSL连接中传入了明文流量。这通常发生在未使用加密通信的节点尝试连接到使用加密通信的节点时。 解决方案 建议您按照以下方式排查: ...
retry_failed=true命令,重新分配分片。 缓存导致资源占用。 建议使用POST /<索引名>/_cache/clear?fielddata=true命令清理缓存。 在进行升配等集群变更操作。 建议中断当前变更,在升配页面选择强制变更,具体操作请参见升配集群。 实例规格较低资源不足,例如1核2 GiB、2核4 GiB等规格。 建议升配集群,具体操作请...
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 ...
出现这个问题的原因是原有分片未正常关闭或者清理,所以当分片要重新分配回出问题节点时就会没办法获取分片锁,这不会导致数据丢失,只需要重新出发一下分配分片的操作即可 failed to obtain in-memory shard lock 1. curl -XPOST "http://192.168.10.10:9200/_cluster/reroute?retry_failed" ...