ElasticSearch: Nicht zugewiesene Shards, wie zu beheben?

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
    }
}'

Standardmäßig weist Elasticsearch Knoten Shards dynamisch neu zu. Wenn Sie jedoch die Shard-Zuordnung deaktiviert haben (möglicherweise haben Sie einen fortlaufenden Neustart durchgeführt und vergessen, ihn erneut zu aktivieren), können Sie die Shard-Zuordnung wieder aktivieren.

# v0.90.x and earlier
curl -XPUT 'localhost:9200/_settings' -d '{
    "index.routing.allocation.disable_allocation": false
}'

# v1.0+
curl -XPUT 'localhost:9200/_cluster/settings' -d '{
    "transient" : {
        "cluster.routing.allocation.enable" : "all"
    }
}'

Elasticsearch weist dann die Scherben wie gewohnt neu zu. Dies kann langsam sein, erwägen Sie das Anheben indices.recovery.max_bytes_per_secund cluster.routing.allocation.node_concurrent_recoveriesbeschleunigen Sie es.

Wenn immer noch Probleme auftreten, stimmt wahrscheinlich etwas anderes nicht. Suchen Sie daher in Ihren Elasticsearch-Protokollen nach Fehlern. Wenn Sie sehen, dass EsRejectedExecutionExceptionIhre Thread-Pools möglicherweise zu klein sind .

Schließlich können Sie einen Shard mit der Umleitungs-API explizit einem Knoten neu zuweisen .

# Suppose shard 4 of index "my-index" is unassigned, so you want to
# assign it to node search03:
curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
    "commands": [{
        "allocate": {
            "index": "my-index",
            "shard": 4,
            "node": "search03",
            "allow_primary": 1
        }
    }]
}'

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:

curl -XPUT 'localhost:9200/<index>/_settings' \
    -d '{"index.routing.allocation.disable_allocation": false}'

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:

curl -XPUT 'localhost:9200/_settings' \
    -d '{"index.routing.allocation.disable_allocation": false}'

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

• Shard Allocation Awareness

Dieses kleine Bash-Skript erzwingt eine brutale Neuzuweisung. Möglicherweise verlieren Sie Daten.

NODE="YOUR NODE NAME"
IFS=$'\n'
for line in $(curl -s 'localhost:9200/_cat/shards' | fgrep UNASSIGNED); do
  INDEX=$(echo $line | (awk '{print $1}'))
  SHARD=$(echo $line | (awk '{print $2}'))

  curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
     "commands": [
        {
            "allocate": {
                "index": "'$INDEX'",
                "shard": '$SHARD',
                "node": "'$NODE'",
                "allow_primary": true
          }
        }
    ]
  }'
done

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:

PUT /myindex/_settings
{
    "index" : {
        "number_of_replicas" : 1
     }
}

Dann:

PUT /myindex/_settings
{
    "index" : {
        "number_of_replicas" : 2
     }
}

(Ich habe es bereits in dieser Frage beantwortet )

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

#!/bin/bash
array=( node1 node2 node3 )
node_counter=0
length=${#array[@]}
IFS=$'\n'
for line in $(curl -s 'http://127.0.0.1:9200/_cat/shards'|  fgrep UNASSIGNED); do
    INDEX=$(echo $line | (awk '{print $1}'))
    SHARD=$(echo $line | (awk '{print $2}'))
    NODE=${array[$node_counter]}
    echo $NODE
    curl -XPOST 'http://127.0.0.1:9200/_cluster/reroute' -d '{
        "commands": [
        {
            "allocate": {
                "index": "'$INDEX'",
                "shard": '$SHARD',
                "node": "'$NODE'",
                "allow_primary": true
            }
        }
        ]
    }'
    node_counter=$(((node_counter)%length +1))
done

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:

#!/usr/bin/env bash

# The script performs force relocation of all unassigned shards, 
# of all indices to a specified node (NODE variable)

ES_HOST="<elasticsearch host>"
NODE="<node name>"

curl ${ES_HOST}:9200/_cat/shards > shards
grep "UNASSIGNED" shards > unassigned_shards

while read LINE; do
  IFS=" " read -r -a ARRAY <<< "$LINE"
  INDEX=${ARRAY[0]}
  SHARD=${ARRAY[1]}

  echo "Relocating:"
  echo "Index: ${INDEX}"
  echo "Shard: ${SHARD}"
  echo "To node: ${NODE}"

  curl -s -XPOST "${ES_HOST}:9200/_cluster/reroute" -d "{
    \"commands\": [
       {
         \"allocate\": {
           \"index\": \"${INDEX}\",
           \"shard\": ${SHARD},
           \"node\": \"${NODE}\",
           \"allow_primary\": true
         }
       }
     ]
  }"; echo
  echo "------------------------------"
done <unassigned_shards

rm shards
rm unassigned_shards

exit 0

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.

In 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:

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.disk.watermark.low": "90%",
    "cluster.routing.allocation.disk.watermark.high": "95%",
    "cluster.info.update.interval": "1m"
  }
}

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.

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! :) :)

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.

PUT /customer
{
    "settings": {
        "number_of_replicas": 0
    }
}

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:

[NO (Zielknotenversion [1.4.2] ist älter als Quellknotenversion [1.4.4])]

Nach der Aktualisierung der alten Knoten auf 1.4.4 begannen diese Knoten mit den anderen guten Knoten zu resnc.

Ich hatte auch dieses Problem und fand einen einfachen Weg, es zu lösen.

• Ruft den Index der nicht zugewiesenen Shards ab

  $ curl -XGET http://172.16.4.140:9200/_cat/shards
  

• Installieren Sie die Kurator-Tools und löschen Sie damit den Index

  $ curator --host 172.16.4.140 delete indices --older-than 1 \
         --timestring '%Y.%m.%d' --time-unit days --prefix logstash
  

  HINWEIS: In meinem Fall ist der Index der Logstash des Tages 2016-04-21

• Dann überprüfen Sie die Scherben erneut, alle nicht zugewiesenen Scherben verschwinden!

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.

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.

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.

# Set how many nodes are expected in this cluster. Once these N nodes
# are up (and recover_after_nodes is met), begin recovery process immediately
# (without waiting for recover_after_time to expire):
#
# gateway.expected_nodes: 2
gateway.expected_nodes: 1

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.

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.

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.

Die Shard-Replikation von der neueren Version auf die vorherigen Versionen funktioniert nicht

Dies kann eine Hauptursache für nicht zugewiesene Shards sein.

Elastische Dokumentation - Rolling Upgrade-Prozess

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.

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.

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.

GET /_cluster/allocation/explain

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 ...

POST /_cluster/reroute

Weitere Hinweise:

• Sehr hilfreich: https://datadoghq.com/blog/elasticsearch-unassigned-shards

• Etwas anderes, das funktionieren könnte. Setzen Sie cluster_concurrent_rebalanceauf 0, dann auf null- 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.}

Ich habe gerade erst die erhöht

"index.number_of_replicas"

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.

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:

curl -XGET http://localhost:9200/_cat/shards |\
  grep UNASSIGNED | grep ' r ' |\
  awk '{print $1}' |\
  xargs -I {} curl -XPUT http://localhost:9200/{}/_settings -H "Content-Type: application/json" \
  -d '{ "index":{ "number_of_replicas": 0}}'

Zurücksetzen auf 1:

curl -XGET http://localhost:9200/_cat/shards |\
  awk '{print $1}' |\
  xargs -I {} curl -XPUT http://localhost:9200/{}/_settings -H "Content-Type: application/json" \
  -d '{ "index":{ "number_of_replicas": 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.