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

Question

我对集群 Elasticsearch 有一个大问题。我有 3 个节点，一个节点停止 Elasticsearch ，集群变红，我用 service elasticsearch restart 重新启动所有节点，现在所有节点都已连接并开始重新分片，但在主节点中大约两个小时后，Elasticsearch 的一个进程使用了​​ 100% 的 cpu，并且在端口 9200/9300 上没有响应，所以集群崩溃了......每个都重复集群重启的时间，不管主节点是什么
我不知道该怎么办，我很绝望，有人可以帮助我吗？

更新
集群的配置是:

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。这完全可以解释他们 react 迟钝；这可能会导致集群管理出现各种问题。这就是为什么他们建议在较大的设置中将主节点与数据节点分开。

一旦修复了无响应的节点(即停止索引，如果仍然存在，如果没有帮助则重新启动)。您可以尝试使用/_cat/shards 和/_cat/indices api 找出哪些索引有问题。此外，日志会告诉您特定分片是否存在任何问题。

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

万一你的集群是黄色的，你可以尝试在那里添加更多节点并重新路由分片。在您的集群变为绿色后，您可以尝试一个一个地删除有问题的节点(永远不要在黄色集群上这样做)。

如果/当您启动并运行时，您需要解决内存不足的原因，否则这种情况会再次发生。它不是无限的数据存储。您可能正在运行昂贵的查询，或者索引过多的数据，或者在做其他显然无法扩展的事情。

几周前我遇到了类似的情况，它的根本原因是一个失控的聚合查询结合了巨大的碎片以及堆上的大量字段数据(这是一个 1.x 集群)。此外，我们在 1.7.4 中遇到了阻止集群重新平衡的已知问题。我修复了它，缓解如下:1)删除我不需要减少分片大小的旧数据 2)增加分片数量，使每个分片更小 3)修复查询以降低成本。 4) 升级到 1.7.5 以防止同样的错误再次杀死我的集群。