ElasticSearch: Nicht zugewiesene Scherben, wie zu beheben?

Standardmäßig ordnet Elasticsearch Knoten dynamisch zu Knoten hinzu. Wenn Sie jedoch die Shard-Zuweisung deaktiviert haben (möglicherweise haben Sie einen Neustart ausgeführt und vergessen, sie erneut zu aktivieren), können Sie die Shard-Zuweisung erneut 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 Shards wie üblich neu zu. Dies kann langsam sein, erwägen Sie, indices.recovery.max_bytes_per_sec und cluster.routing.allocation.node_concurrent_recoveries zu erhöhen, um es zu beschleunigen.

Wenn immer noch Probleme auftreten, ist wahrscheinlich etwas anderes falsch. Schauen Sie in Ihren Elasticsearch-Protokollen nach Fehlern. Wenn Sie EsRejectedExecutionException sehen, sind Ihre Thread-Pools möglicherweise zu klein .

Schließlich können Sie einen Knoten explizit mit dem Reroute API 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
        }
    }]
}'

Dieses kleine Bash-Skript wird die Neuzuweisung brutal erzwingen, es können Daten verloren gehen.

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 funktionierte, war das Ändern der number_of_replicas (ich hatte 2 Repliken, also habe ich es auf 1 geändert und dann wieder auf 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 diese Frage geantwortet)

Elasticsearch ordnet automatisch Shards zu, wenn die folgende Konfiguration für alle festgelegt ist. Diese Konfiguration kann auch über eine rest-API eingestellt werdencluster.routing.allocation.enable: all

Wenn es auch nach Anwendung der folgenden Konfiguration nicht gelingt, die Shards automatisch zuzuweisen, müssen Sie die Shards selbst zwingen. ES offiziellen Link für diese

Ich habe ein Skript geschrieben, um alle nicht zugewiesenen Shards über das Cluster hinweg zuzuweisen.

das folgende Array enthält eine Liste von Knoten, zwischen 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 Thema der Shards-Zuordnung beschäftigt. Das Skript, das W. Andrew Loe III in seiner Antwort vorgeschlagen hat, hat für mich nicht funktioniert, also habe ich es ein wenig geändert 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

Nun, ich bin keine Art Bash-Guru, aber das Skript 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 der obere Festplattenspeicherplatz erreicht.

Schauen Sie sich diesen Artikel an: https://www.elastic.co/guide/de/elasticsearch/reference/current/disk-allocator.html

Im Grunde 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 wird zugewiesen, wenn <90% Festplattenspeicher belegt sind, und ein Shard wird auf einen anderen Computer im Cluster verschoben, wenn> 95% Festplattenspeicher verwendet wird. und es prüft alle 1 Minute.

Vielleicht hilft es jemandem, aber ich hatte das gleiche Problem und es lag an mangelndem Speicherplatz, weil ein Protokoll zu groß wurde.

Hoffe es hilft jemandem! :)

In meinem Fall, wenn ich ein neuesindexerstelle, wird der Standardwertnumber_of_replicasauf 1 gesetzt Extra-Knoten zum Erstellen des Replikats, sodass der Zustand gelb wurde. Wenn ich also den Index mitsettingsproperty erstellt und die number_of_replicas auf 0 gesetzt habe, dann 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 (Einstellung von "index.routing.allocation.disable_allocation" auf false und Einstellung von "cluster.routing.allocation.enable" auf "all") funktionierte nicht. 

Die Antwort von @Wilfred Hughes (Einstellung von "cluster.routing.allocation.enable" auf "all" unter Verwendung von Transient) ergab jedoch einen Fehler mit folgender Anweisung:

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

Nach dem Update der alten Knoten auf 1.4.4 begannen diese Knoten, sich mit den anderen guten Knoten zu verbinden.

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

• Holen Sie sich den Index der nicht zugewiesenen Shards

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

• Installieren Sie die Kurator-Tools und löschen Sie 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 Logstash des Tages 2016-04-21

• Dann überprüfen Sie die Scherben noch einmal, alle nicht zugewiesenen Scherben gehen weg!

Ich begegne dieser Situation auch und habe sie schließlich behoben.

Zuerst werde ich meine Situation beschreiben. Ich habe zwei Knoten im ElasticSearch-Cluster, sie können sich finden, aber wenn ich einen Index mit den Einstellungen "number_of_replicas" erstellt habe: 2 , "number_of_shards": 5, zeigt ES ein gelbes Signal und unassigned_shards 5.

Das Problem tritt auf, weil der Wert von number_of_replicas , wenn ich seinen Wert mit 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 oben genannten Vorschläge ausprobiert und leider hat keiner davon funktioniert. Wir haben einen "Log" -Index in unserer unteren Umgebung, in dem Apps Fehler schreiben. Es ist ein Cluster mit einem einzigen Knoten. Was für mich gelöst wurde, war das Überprüfen der YML-Konfigurationsdatei für den Knoten und die Standardeinstellung "gateway.expected_nodes: 2". Dies hatte Vorrang vor allen anderen Einstellungen, die wir hatten. Wann immer wir einen Index für diesen Knoten erstellen würden, würde er versuchen, 3 von 5 Shards auf den zweiten Phantomknoten zu verteilen. Diese würden daher als nicht zugewiesen angezeigt und könnten niemals zum ersten und einzigen Knoten verschoben werden.

Die Lösung bestand darin, die Konfiguration zu bearbeiten, die Einstellung "gateway.expected_nodes" auf 1 zu setzen, so dass die Suche nach dem nie zu findenden Bruder im Cluster aufhörte 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 war 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 durch Ausführen von der Dev-Konsole behoben: "POST/_cluster/reroute? Retry_failed"

.....

Ich schaute zuerst in die Indexliste, um zu sehen, welche Indizes rot waren und lief dann 

"get /_cat/shards?h=[INDEXNAME ?,shard,prirep,state,unassigned.reason"

und sah, dass Splitter im Zustand ALLOCATION_FAILED hängen geblieben waren. Durch das Ausführen des obigen Wiederholungsversuchs mussten sie die Zuweisung erneut versuchen.

Ich hatte zwei Indizes mit nicht zugewiesenen Scherben, die sich nicht selbst zu heilen schienen. Ich habe dies schließlich gelöst, indem ich vorübergehend einen zusätzlichen Datenknoten hinzufügte ^[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) ausbalancieren und in einen gesunden Zustand versetzen.

Es ist eine gute Idee zu vermeiden, mehrere Datenknoten gleichzeitig zu töten (so bin ich in diesen Zustand gekommen). Wahrscheinlich habe ich keine Kopien/Repliken für mindestens einen der Shards aufbewahrt. Glücklicherweise behielt Kubernetes den Festplattenspeicher bei und verwendete ihn wieder, als ich den Datenknoten neu startete.

... einige Zeit ist vergangen ...

Nun, dieses Mal schien das Hinzufügen eines Knotens nicht zu funktionieren (nachdem ich einige Minuten gewartet hatte, bis etwas passierte), also fing ich an, mich in der REST API) umzusehen.

GET /_cluster/allocation/explain

Dies zeigte meinen neuen Knoten mit "decision": "YES".

Übrigens hatten alle vorhandenen Knoten "decision": "NO" wegen "the node is above the low watermark cluster setting". Das war also wahrscheinlich ein anderer Fall als der, den ich zuvor angesprochen hatte.

Dann habe ich den folgenden einfachen POST gemacht^[2]  ohne Körper , der die Dinge in Gang brachte ...

POST /_cluster/reroute

Weitere Hinweise:

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

• Etwas anderes, das möglicherweise funktioniert. Einstellen cluster_concurrent_rebalance bis 0, dann zu null - wie ich demonstriere hier .

^{[1] In Kubernetes ist das ziemlich einfach, wenn Sie über genügend Headroom verfügen: Skalieren Sie den Stateful-Satz einfach über das Dashboard.}

^{[2] Mit der Kibana "Dev Tools" -Schnittstelle musste ich mich nicht um SSH/exec-Shells kümmern.}

Wenn Sie mit beschädigten Shards arbeiten, können Sie den Replikationsfaktor auf 0 und dann auf den ursprünglichen Wert zurücksetzen. Dadurch sollten die meisten, wenn nicht alle beschädigten Shards gelöscht und die neuen Replikate in den Cluster verschoben werden.

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.

Ich habe versucht, nicht zugewiesene Shards zu löschen oder sie manuell einem bestimmten Datenknoten zuzuweisen. Es funktionierte nicht, weil nicht zugewiesene Shards immer wieder 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 töte sie. Problem ist nicht mehr reproduzierbar.

Könnte helfen, aber ich hatte dieses Problem, als ich versuchte, ES im eingebetteten Modus auszuführen. Es wurde behoben, um sicherzustellen, dass der Knoten lokal (true) festgelegt wurde.

Ich habe gerade erst das erhöht

"index.number_of_replicas"

um 1 (warten, bis die Knoten synchronisiert sind) und anschließend um 1 verringern, 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 fällt mir leichter.

Hoffe das hilft.

Ein weiterer möglicher Grund für nicht zugewiesene Shards besteht darin, dass in Ihrem Cluster mehr als eine Version der Elasticsearch-Binärdatei ausgeführt wird.

shard-Replikation von der neueren Version zur vorherigen Versionen werden nicht funktionieren

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

Elastic Documentation - Rolling Upgrade-Prozess

Ich habe genau die gleiche Ausgabe gefunden. Dies kann verhindert werden, indem die Shardzuordnung vor dem Neustart der elastischen Suche vorübergehend auf "false" gesetzt wird. Die nicht zugewiesenen Shards werden jedoch nicht korrigiert, wenn sie bereits vorhanden sind.

In meinem Fall wurde dies durch mangelnden freien Speicherplatz auf dem Datenknoten verursacht. Die nicht zugewiesenen Shards befanden sich nach dem Neustart noch auf dem Datenknoten, wurden jedoch vom Master nicht erkannt. 

Durch das Bereinigen eines der Knoten von der Festplatte wurde 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.