Question

我对群集弹性搜索有一个很大的问题。我有3个节点，一个节点已停止弹性搜索，集群变为红色，我已用service elasticsearch restart重新启动所有节点，现在所有节点都已连接并开始重新分片但在主节点中大约两个小时后，一个进程Elasticsearch使用100％的CPU并且在端口9200/9300上没有响应，因此群集会崩溃...每次重新启动群集时都会重复此操作，无论主服务器是什么我不知道该怎么办，我绝望，有人可以帮助我吗？

UPDATE 集群的配置是：

cluster.name: es-cluster
node.name: es-node1
bootstrap.mlockall: true
discovery.zen.ping.unicast.hosts: ["ec2-52-208-103-xxx.eu-west-1.compute.amazonaws.com", "ec2-52-51-160-xxx.eu-west-1.compute.amazonaws.com", "ec2-52-208-167-xxx.eu-west-1.compute.amazonaws.com"]
discovery.zen.minimum_master_nodes: 2
discovery.zen.ping.multicast.enabled: false
node.master: true
node.data: true
network.bind_host: 0.0.0.0
network.publish_host: ec2-52-208-103-xxx.eu-west-1.compute.amazonaws.com

所有节点异常network.publish_host和node.name的配置是否相同现在集群ID减少到2个节点并且重新分片正在进行中，完成后我仍然可以使用集群？也许这是错误的配置？它正常运作数月

Answer 1

Elasticsearch的哪个版本？关于你可能遇到的错误的问题。

您的群组处于什么状态？检查/ _cluster / health

检查日志以查找每个节点上的错误。可能所有节点都是垃圾收集和内存不足。如果是这样，日志将满了垃圾收集相关的警告，也可能是一些OutOfMemoryExceptions。这将完全解释他们没有反应;这会导致集群管理出现各种问题。这就是为什么他们建议在较大的设置中将主节点与数据节点分开。

修复无响应的节点后（即停止索引，如果仍然存在，请重新启动，如果这不起作用）。您可以尝试使用/ _cat / shards和/ _cat / indices apis来确定哪些索引存在问题。此外，日志将告诉您特定分片是否存在任何问题。

此时您的群集是红色的，可能是由于您之前的重启（不要这样做，这是将群集从黄色变为红色的可靠方法）。所以你可能会丢失一些数据。您可能还有几个未分配的分片。如果您仍然有一个主分片，您可以尝试将副本数量减少到0，然后再次增加（危险，小心）。这有时可以帮助推动群集恢复健康。或者，如果您不关心受影响的指数，请将其删除。

在快乐的情况下，您的群集是黄色的，您可以尝试添加更多节点并在那里重新路由分片。群集变绿后，您可以尝试逐个删除有问题的节点（不要在黄色群集上执行此操作）。

如果/当你开始运行时，你需要解决内存不足的原因或者这种情况会再次发生。它不是一个无限的数据存储区。您可能要么运行昂贵的查询，要么索引过多的数据，要么做一些显然无法扩展的事情。

几周前我遇到了类似的情况并且根本导致了一个失控的聚合查询以及堆上有大量字段数据的巨大分片（这是一个1.x集群）。此外，我们遇到了1.7.4的已知问题，这些问题阻止了集群的重新平衡。我修复它如下：1）删除我不需要减少分片大小的旧数据2）增加分片数量，使每个分片更小3）修复查询更便宜。 4）升级到1.7.5以防止同样的bug再次杀死我的集群。

Elasticsearch集群在重新分片期间失败

1 个答案: