Elasticsearch cluster scheitern beim Nachhärten

Question

Ich habe ein großes Problem mit einem Cluster elasticsearch. Ich habe 3 Knoten, ein Knoten hat elasticsearch gestoppt und der Cluster geht auf rot, ich habe alle Knoten mit service elasticsearch restart neu gestartet, jetzt sind alle Knoten verbunden und beginnen nach Neuschleifen, aber nach etwa zwei Stunden im Master-Knoten verwendet ein Prozess von Elasticsearch 100 % der CPU und reagiert nicht auf Port 9200/9300, so dass der Cluster fallen ... Dies wird bei jedem Neustart des Clusters wiederholt, unabhängig davon, was der Master Ich weiß nicht, was zu tun ist, ich bin verzweifelt, jemand kann mir helfen ?

UPDATE Die Konfiguration des Clusters ist:

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 

Ist die gleiche Konfiguration für alle Knoten Ausnahme network.publish_host und node.name Nun ist die Cluster-ID-2-Knoten reduziert und das resharding im Gang ist, wenn ich kann, fertig Benutze den Cluster trotzdem? Vielleicht ist es die falsche Konfiguration? Es funktioniert seit Monaten einwandfrei

Answer 1

Welche Version von Elasticsearch? Eine Art von Angelegenheit in Bezug auf Fehler, denen Sie möglicherweise begegnen.

In welchem ​​Status befindet sich Ihr Cluster? Überprüfen Sie/_cluster/Gesundheit

Überprüfen Sie die Protokolle für Fehler auf jedem Knoten. Vermutlich sind alle Ihre Knoten entweder Müllsammlung und nicht genügend Speicher. Wenn dies der Fall ist, ist das Protokoll voll mit Warnungen zum Sammeln von Abfällen und möglicherweise auch mit einigen OutOfMemoryExceptions. Das würde erklären, dass sie nicht reagieren. Dies kann bei der Clusterverwaltung zu Problemen führen. Aus diesem Grund empfehlen sie, Master-Knoten in größeren Konfigurationen von Datenknoten zu trennen.

Sobald Sie nicht reagierende Knoten reparieren (d. H. Die Indizierung stoppen, wenn Sie noch sind, starten Sie neu, wenn das nicht hilft). Sie können versuchen, die/_cat/shards und/_cat/indexes apis zu verwenden, um herauszufinden, welche Indizes problematisch sind. In den Protokollen erfahren Sie auch, ob es Probleme mit bestimmten Shards gibt.

Ihr Cluster ist zu diesem Zeitpunkt wahrscheinlich aufgrund Ihres früheren Neustarts rot (tun Sie dies nie, dies ist eine sichere Methode, um Ihren Cluster von gelb nach rot zu bringen). Sie werden wahrscheinlich einige Daten verlieren. Sie haben wahrscheinlich auch mehrere nicht zugewiesene Shards. Wenn Sie immer noch einen primären Shard haben, könnten Sie versuchen, die Anzahl der Replikate auf 0 zu reduzieren und dann wieder zu erhöhen (gefährlich, seien Sie vorsichtig). Dies kann manchmal helfen, einen Cluster wieder in den Normalzustand zu bringen. Wenn Sie die betroffenen Indizes nicht interessieren, löschen Sie sie.

Im glücklichen Fall ist Ihr Cluster gelb, Sie können versuchen, weitere Knoten hinzuzufügen und Shards neu zu routen. Nachdem Ihr Cluster grün wird, können Sie versuchen, problematische Knoten einzeln zu entfernen (tun Sie dies nie auf einem gelben Cluster).

Wenn/wann Sie die Dinge in Betrieb nehmen, müssen Sie die Gründe ansprechen, aus denen der Arbeitsspeicher knapp wird, oder dies wird wieder vorkommen. Es ist kein unendlicher Datenspeicher. Wahrscheinlich führen Sie entweder teure Abfragen aus oder indexieren zu viele Daten oder machen etwas anderes, das nicht skalierbar ist.

Ich hatte vor ein paar Wochen eine ähnliche Situation und Root-verursachte es zu einer außer Kontrolle Aggregation Abfrage mit riesigen Shards mit vielen Felddaten auf dem Haufen (das war ein 1.x-Cluster) kombiniert. Außerdem sind wir auf bekannte Probleme mit Version 1.7.4 gestoßen, die eine Neuverteilung des Clusters verhinderten. Ich reparierte es gemildert wie folgt: 1) lösche alte Daten, die ich nicht brauchte, um Shardgröße zu reduzieren 2) erhöhe die Anzahl von Shards, so dass jeder Shard kleiner ist 3) repariere die Abfrage, um weniger teuer zu sein. 4) Aktualisieren Sie auf 1.7.5, um zu verhindern, dass derselbe Fehler erneut den Cluster zerstört.