Ich habe einen ES-Cluster mit 4 Knoten:
number_of_replicas: 1
search01 - master: false, data: false
search02 - master: true, data: true
search03 - master: false, data: true
search04 - master: false, data: true
Ich musste search03 neu starten, und als es zurückkam, trat es problemlos wieder in den Cluster ein, ließ aber 7 nicht zugewiesene Shards herumliegen.
{
"cluster_name" : "tweedle",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 4,
"number_of_data_nodes" : 3,
"active_primary_shards" : 15,
"active_shards" : 23,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 7
}
Jetzt befindet sich mein Cluster im gelben Zustand. Was ist der beste Weg, um dieses Problem zu beheben?
- Splitter löschen (abbrechen)?
- Verschieben Sie die Shards auf einen anderen Knoten?
- Die Shards dem Knoten zuordnen?
- 'Number_of_replicas' auf 2 aktualisieren?
- Etwas ganz anderes?
Interessanterweise begann dieser Knoten, als ein neuer Index hinzugefügt wurde, daran zu arbeiten und spielte gut mit dem Rest des Clusters. Er ließ nur die nicht zugewiesenen Shards herumliegen.
Folgen Sie der Frage: Mache ich etwas falsch, damit dies überhaupt passiert? Ich habe nicht viel Vertrauen in einen Cluster, der sich beim Neustart eines Knotens so verhält.
ANMERKUNG: Wenn Sie aus irgendeinem Grund einen einzelnen Knotencluster ausführen, müssen Sie möglicherweise einfach Folgendes tun:
curl -XPUT 'localhost:9200/_settings' -d '
{
"index" : {
"number_of_replicas" : 0
}
}'
quelle
{ "error" : "ElasticsearchIllegalArgumentException[[allocate] failed to find [logstash-2015.01.05][1] on the list of unassigned shards]", "status" : 400 }
Obwohl ich sehen kann, dass Scherbe eine der nicht zugewiesenen in ES-Head ist-H 'Content-Type: application/json'
wenn Sie den Fehler erhaltenContent-Type header [application/x-www-form-urlencoded] is not supported
OK, ich habe dies mit Hilfe des ES-Supports gelöst. Geben Sie auf allen Knoten (oder den Knoten, von denen Sie glauben, dass sie die Ursache des Problems sind) den folgenden Befehl an die API aus:
Wo
<index>
ist der Index, von dem Sie glauben, dass er der Schuldige ist? Wenn Sie keine Ahnung haben, führen Sie dies einfach auf allen Knoten aus:Ich habe diese Zeile auch zu meiner yaml-Konfiguration hinzugefügt und seitdem waren alle Neustarts des Servers / Dienstes problemlos. Die Scherben werden sofort wieder neu zugewiesen.
FWIW, um eine häufig nachgefragte Frage zu beantworten, setzen Sie MAX_HEAP_SIZE auf 30 G, es sei denn, Ihr Computer verfügt über weniger als 60 G RAM. In diesem Fall stellen Sie die Hälfte des verfügbaren Speichers ein.
Verweise
quelle
index.routing.allocation.disable_allocation : false cluster.routing.allocation.enable: none
Aber immer noch zeigen sich die nicht zugewiesenen Scherben. Was kann der Grund sein?{ "type": "illegal_argument_exception", "reason": "unknown setting [index.routing.allocation.disable_allocation] please check that any required plugins are installed, or check the breaking changes documentation for removed settings" } ],
Dieses kleine Bash-Skript erzwingt eine brutale Neuzuweisung. Möglicherweise verlieren Sie Daten.
quelle
{"error":"Content-Type header [application/x-www-form-urlencoded] is not supported","status":406}{"error":"Content-Type header [application/x-www-form-urlencoded] is not supported","status":406}
Das einzige, was für mich funktioniert hat, war das Ändern der Anzahl der Replikate (ich hatte 2 Replikate, also habe ich sie in 1 und dann wieder in 2 geändert).
Zuerst:
Dann:
(Ich habe es bereits in dieser Frage beantwortet )
quelle
Elasticsearch weist Shards automatisch zu, wenn die folgende Konfiguration auf alle eingestellt ist. Diese Konfiguration kann auch über eine Rest-API festgelegt werden. Cluster.routing.allocation.enable: all
Wenn es auch nach Anwendung der folgenden Konfiguration nicht möglich ist, die Shards automatisch zuzuweisen, müssen Sie die Zuweisung der Shards selbst erzwingen. ES offizieller Link dazu
Ich habe ein Skript geschrieben, um die Zuweisung aller nicht zugewiesenen Shards im Cluster zu erzwingen.
Das folgende Array enthält eine Liste der Knoten, unter denen Sie die nicht zugewiesenen Shards ausgleichen möchten
quelle
Ich habe mich heute mit dem gleichen Problem der Zuweisung von Scherben beschäftigt. Das Skript, das W. Andrew Loe III in seiner Antwort vorgeschlagen hat, hat bei mir nicht funktioniert, also habe ich es ein wenig modifiziert und es hat endlich funktioniert:
Jetzt bin ich kein Bash-Guru, aber das Drehbuch hat wirklich für meinen Fall funktioniert. Beachten Sie, dass Sie geeignete Werte für die Variablen "ES_HOST" und "NODE" angeben müssen.
quelle
allocate
durchallocate_empty_primary
und ersetzen Sie es\"allow_primary\": true
durch\"accept_data_loss\": true
{"error":"Content-Type header [application/x-www-form-urlencoded] is not supported","status":406}
auch nach Fawix Vorschlag AnwendungIn meinem Fall wurde die Obergrenze des Festplattenspeichers erreicht.
Schauen Sie sich diesen Artikel an: https://www.elastic.co/guide/en/elasticsearch/reference/current/disk-allocator.html
Grundsätzlich lief ich:
Damit es zugewiesen wird, wenn <90% Festplattenspeicher verwendet wird, und ein Shard auf einen anderen Computer im Cluster verschoben wird, wenn> 95% Festplattenspeicher verwendet wird; und es überprüft alle 1 Minute.
quelle
Vielleicht hilft es jemandem, aber ich hatte das gleiche Problem und es lag an einem Mangel an Speicherplatz, der durch ein viel zu großes Protokoll verursacht wurde.
Hoffe es hilft jemandem! :) :)
quelle
In meinem Fall wird beim Erstellen eines neuen Index die Standardanzahl der Replikate auf 1 festgelegt. Die Anzahl der Knoten in meinem Cluster war nur einer, sodass kein zusätzlicher Knoten zum Erstellen des Replikats vorhanden war, sodass der Zustand gelb wurde. Als ich also den Index mit der Eigenschaft settings erstellt und die Anzahl der Replikate auf 0 gesetzt habe, hat es gut funktioniert. Hoffe das hilft.
quelle
Ich hatte das gleiche Problem, aber die Hauptursache war ein Unterschied in den Versionsnummern (1.4.2 auf zwei Knoten (mit Problemen) und 1.4.4 auf zwei Knoten (ok)). Die erste und zweite Antwort (Setzen von "index.routing.allocation.disable_allocation" auf false und Setzen von "cluster.routing.allocation.enable" auf "all") funktionierten nicht.
Die Antwort von @Wilfred Hughes (Setzen von "cluster.routing.allocation.enable" auf "all" unter Verwendung von transient) ergab jedoch einen Fehler mit der folgenden Aussage:
Nach der Aktualisierung der alten Knoten auf 1.4.4 begannen diese Knoten mit den anderen guten Knoten zu resnc.
quelle
Ich hatte auch dieses Problem und fand einen einfachen Weg, es zu lösen.
Ruft den Index der nicht zugewiesenen Shards ab
Installieren Sie die Kurator-Tools und löschen Sie damit den Index
HINWEIS: In meinem Fall ist der Index der Logstash des Tages 2016-04-21
quelle
curator_cli --host 127.0.0.1 delete_indices --filter_list '[{"filtertype":"pattern","kind":"prefix","value":"logstash-"}]'
Ich treffe auch diese Situation und habe sie endlich behoben.
Zunächst werde ich meine Situation beschreiben. Ich habe zwei Knoten im ElasticSearch-Cluster, die sich gegenseitig finden können. Wenn ich jedoch einen Index mit den Einstellungen "number_of_replicas": 2 , "number_of_shards": 5 erstellt habe, zeigt ES ein gelbes Signal und unassigned_shards ist 5.
Das Problem tritt auf, weil der Wert von number_of_replicas , wenn ich seinen Wert auf 1 setze , alles in Ordnung ist.
quelle
In meinem Fall trat ein alter Knoten mit alten Freigaben dem Cluster bei, sodass wir den alten Knoten herunterfahren und die Indizes mit nicht zugewiesenen Shards löschen mussten.
quelle
Ich habe einige der obigen Vorschläge ausprobiert und leider hat keiner von ihnen funktioniert. Wir haben einen "Log" -Index in unserer unteren Umgebung, in den Apps ihre Fehler schreiben. Es ist ein einzelner Knotencluster. Was es für mich gelöst hat, war, die YML-Konfigurationsdatei für den Knoten zu überprüfen und festzustellen, dass sie immer noch die Standardeinstellung "gateway.expected_nodes: 2" hatte. Dies überschrieb alle anderen Einstellungen, die wir hatten. Wann immer wir einen Index für diesen Knoten erstellen, wird versucht, 3 von 5 Shards auf den Phantom-2-Knoten zu verteilen. Diese würden daher als nicht zugewiesen erscheinen und könnten niemals auf den ersten und einzigen Knoten verschoben werden.
Die Lösung bestand darin, die Konfiguration zu bearbeiten, die Einstellung "gateway.expected_nodes" auf 1 zu ändern, damit die Suche nach dem nie zu findenden Bruder im Cluster beendet und die Elastic-Dienstinstanz neu gestartet wurde. Außerdem musste ich den Index löschen und einen neuen erstellen. Nach dem Erstellen des Index wurden alle Shards auf dem ersten und einzigen Knoten angezeigt, und keiner wurde nicht zugewiesen.
quelle
Für mich wurde dies behoben, indem dies über die Entwicklungskonsole ausgeführt wurde: "POST / _cluster / reroute? Retry_failed"
..... .....
Ich habe zunächst in der Indexliste nachgesehen, welche Indizes rot waren, und bin dann gelaufen
"get /_cat/shards?h=[INDEXNAME‹,shard,prirep,state,unassigned.reason"
und sah, dass Shards im Status ALLOCATION_FAILED stecken geblieben waren, sodass sie durch Ausführen des obigen Wiederholungsversuchs die Zuordnung erneut versuchten.
quelle
Könnte helfen, aber ich hatte dieses Problem, als ich versuchte, ES im eingebetteten Modus auszuführen. Korrektur war, um sicherzustellen, dass der Knoten lokal (wahr) gesetzt war.
quelle
Ein weiterer möglicher Grund für nicht zugewiesene Shards ist, dass in Ihrem Cluster mehr als eine Version der Elasticsearch-Binärdatei ausgeführt wird.
Dies kann eine Hauptursache für nicht zugewiesene Shards sein.
Elastische Dokumentation - Rolling Upgrade-Prozess
quelle
Ich bin auf genau das gleiche Problem gestoßen. Dies kann verhindert werden, indem die Shard-Zuordnung vorübergehend auf false gesetzt wird, bevor elasticsearch neu gestartet wird. Dadurch werden die nicht zugewiesenen Shards jedoch nicht behoben, wenn sie bereits vorhanden sind.
In meinem Fall wurde dies durch den Mangel an freiem Speicherplatz auf dem Datenknoten verursacht. Die nicht zugewiesenen Shards befanden sich nach dem Neustart noch auf dem Datenknoten, wurden jedoch vom Master nicht erkannt.
Wenn Sie nur einen der Knoten von der Festplatte entfernen, wird der Replikationsprozess für mich gestartet. Dies ist ein ziemlich langsamer Prozess, da alle Daten von einem Datenknoten auf den anderen kopiert werden müssen.
quelle
Ich habe versucht, nicht zugewiesene Shards zu löschen oder sie manuell einem bestimmten Datenknoten zuzuweisen. Es funktionierte nicht, weil immer wieder nicht zugewiesene Scherben auftauchten und der Gesundheitszustand immer wieder "rot" war. Dann bemerkte ich, dass einer der Datenknoten im "Neustart" -Zustand steckte. Ich reduziere die Anzahl der Datenknoten und habe sie getötet. Problem ist nicht mehr reproduzierbar.
quelle
Ich hatte zwei Indizes mit nicht zugewiesenen Scherben, die nicht selbstheilend zu sein schienen. Ich habe dies schließlich behoben, indem ich vorübergehend einen zusätzlichen Datenknoten hinzugefügt habe [1] . Nachdem die Indizes gesund geworden waren und sich alles auf Grün stabilisiert hatte, entfernte ich den zusätzlichen Knoten und das System konnte sich (wieder) neu ausbalancieren und einen gesunden Zustand erreichen.
Es ist eine gute Idee, nicht mehrere Datenknoten gleichzeitig zu töten (so bin ich in diesen Zustand gekommen). Wahrscheinlich hatte ich keine Kopien / Repliken für mindestens eine der Scherben aufbewahrt. Glücklicherweise behielt Kubernetes den Festplattenspeicher bei und verwendete ihn wieder, als ich den Datenknoten neu startete.
... Einige Zeit ist vergangen ...
Nun, diesmal schien das Hinzufügen eines Knotens nicht zu funktionieren (nachdem ich einige Minuten darauf gewartet hatte, dass etwas passiert), also fing ich an, in der REST-API herumzustöbern.
Dies zeigte meinen neuen Knoten mit
"decision": "YES"
.Übrigens hatten alle bereits vorhandenen Knoten
"decision": "NO"
aufgrund"the node is above the low watermark cluster setting"
. Dies war also wahrscheinlich ein anderer Fall als der, den ich zuvor angesprochen hatte.Dann habe ich den folgenden einfachen POST [2] ohne Körper gemacht , der die Dinge in Gang gebracht hat ...
Weitere Hinweise:
Sehr hilfreich: https://datadoghq.com/blog/elasticsearch-unassigned-shards
Etwas anderes, das funktionieren könnte. Setzen Sie
cluster_concurrent_rebalance
auf0
, dann aufnull
- wie ich hier demonstriere .[1] In Kubernetes ziemlich einfach, wenn Sie genügend Headroom haben: Skalieren Sie einfach das Stateful-Set über das Dashboard.
[2] Über die Kibana "Dev Tools" -Schnittstelle musste ich mich nicht mit SSH / Exec-Shells beschäftigen.
quelle
Ich habe gerade erst die erhöht
um 1 (warten Sie, bis die Knoten synchronisiert sind) und anschließend um 1 verringert, wodurch die nicht zugewiesenen Shards effektiv entfernt werden und der Cluster wieder grün ist, ohne dass das Risiko besteht, Daten zu verlieren.
Ich glaube, es gibt bessere Wege, aber das ist einfacher für mich.
Hoffe das hilft.
quelle
Wenn Sie mit beschädigten Shards arbeiten, können Sie den Replikationsfaktor auf 0 setzen und dann auf den ursprünglichen Wert zurücksetzen. Dies sollte die meisten, wenn nicht alle beschädigten Shards beseitigen und die neuen Replikate im Cluster verschieben.
Festlegen von Indizes mit nicht zugewiesenen Replikaten zur Verwendung eines Replikationsfaktors von 0:
Zurücksetzen auf 1:
Hinweis: Führen Sie dies nicht aus, wenn Sie unterschiedliche Replikationsfaktoren für unterschiedliche Indizes haben. Dies würde den Replikationsfaktor für alle Indizes auf 1 fest codieren.
quelle