/
ElasticSearch: Was tun bei unassigned Shards?

ElasticSearch: Was tun bei unassigned Shards?

Owned by Former user (Deleted)

ElasticSearch ist die Volltextdatenbank. Sie besteht aus mehreren Shards, siehe auch: ElasticSearch: Wofür ist welcher Shard?

Nur wenn alle Shards geladen sind, funktionieren Volltextverarbeitung und Volltextsuche. Unassigend bedeutet, dass ein Shard nicht geladen wurde oder nicht geladen werden kann. 
Ablauf Shard laden: unassigned >> initialized >> started 
Unser Wunsch ist, dass alle Shards started sind. Bsp.:


Es kann viele Gründe geben, warum ein Shard nicht geladen werden kann. Das kann Fehlkonfiguration sein oder Fehler.

Bisher bekannte Probleme/Fehler:

  1. nicht genug Plattenplatz verfügbar. 
  2. Es gibt nur 1 Elasticsearch-Server und Replicas wurden aktiviert.
  3. Es gibt mehrere Elasticsearch-Server und es wurden mehr als 1 Shard aktiviert und ein Server ist ausgefallen. 
  4. Der RAM reicht nicht mehr aus, um die Daten zu verwalten.  
  5. Es gab Störungen und die Replikation / Verarbeitung wurde unterbrochen oder ist auf einen Timeout gelaufen 
  6. Es gab Plattenfehlern/Netzwerkfehler ... und Daten sind kaputt. 
  7. Das Laden der Shards dauert nur einfach lange, weil sie zu groß sind. 
  8. Volltext-Daten irreparabel 
  9. Fehler in den Tranaktionslogs
  10. es gibt corrupt* Dateien. 
  11. eine Lock-Datei ist defekt und kann nicht geladen werden. 

Schritt-für-Schritt-Anleitung

Für alle Fehlerfälle: 

  1. prüfen, welches der oben genannten Fehler zutrifft. Dazu den Link aufrufen: 
    http://<elasticsearch-server>:8041/_cat/shards?v 
    Bsp.: http://127.0.0.1:8041/_cat/shards?v
  2. Welche Shards sind unassigend? Oder gibt es welche, die auf Initialisierung stehen? Bei diesem Link kann man sehen, ob die Daten noch am Laden sind:
    http://<elasticsearch-server>:8041/_cat/recovery?v 
    Bsp.: http://127.0.0.1:8041/_cat/recovery?v
  3. Wenn sich nichts mehr tut oder nach dem Init-Versuch die Daten wieder auf unassigned stehen, dann prüfen, ob im Log hilfreiche Informationen stehen. 
  4. Hilfreich ist auch dieser Link (listet alle unassigned Shards auf) und manchmal eine Fehlerursache:
    siehe auch: https://www.elastic.co/guide/en/elasticsearch/reference/6.8/cluster-allocation-explain.html?baymax=rec&rogue=rec-1&elektra=guide
    http://<elasticsearch-server>:8041/_cluster/allocation/explain?include_disk_info=true
    Bsp.: http://127.0.0.1:8041/_cluster/allocation/explain?include_disk_info=true
  5. Anhand der Fehlerfälle wie nachfolgend beschrieben vorgehen.
    Beispiel-Ergebnis: hier wurden identische Shards auf 2 Server gefunden. Das Laden wir automatisch unterbunden. 
  6. Wenn in den Anzeigen nicht zu erkenne ist, welcher Fehler auftritt, dann das ElasticSearch-Log aktivieren. Dazu die log4j2.properties anpassen. "rootLogger.level" von "info" auf "debug" stellen und ElasticSearch neu starten. Es empfiehlt sich, vor dem Dienststart das Log-Verzeichnis zu leeren. Bitte daran denken nach der Analyse dies wieder zurück auf "info" stellen! 


für Punkt 1: Plattenplatzproblem

  1. Plattenplatz schaffen und ElasticSearch neu starten.
  2. Manchmal wird ElasticSearch auch in den ReadOnly-Modus geschaltet. 


für Punkt 2: Replicas aktiviert bei 1 ElasticSearch-Server 

  1. ElasticSearch lässt nicht zu, dass Replica (= Kopie eines Shards) auf dem gleichen Server aktiviert wird. Daher werden die Replicas automatisch nicht geladen bzw. auf unassigned gestellt. 
  2. Replicas deaktivieren, siehe ElasticSearch: Wie aktiviert/deaktiviert man die Replikation?. Anstelle 1 bei number_of_replicas 0 eintragen. Das bitte für alle Shards ausführen!


für Punkt 3: mehr als 1 Replica aktiviert bei mehreren ElasticSearch-Server 

  1. Hier sollte zunächst die Frage gestellt werden: Sollte das so ein?
    Number_of_replicas bezeichnet die Anzahl an Kopieen für 1 Shard.  { "number_of_replicas": 2 } Bedeutet, die Anzahl an Kopieen, nicht die Anzahl der Server. Gibt es z. Bsp. nur 3 Server und einer fällt aus, kann es passieren, dass ElasticSearch die Replicas automatisch unassigned stellt, siehe vorheriger Fehlerfall.  
  2. Sollte die Antwort auf die vorherige Frage "nein" sein, dann number_of_replicas auf 1 reduzieren, siehe ElasticSearch: Wie aktiviert/deaktiviert man die Replikation?.
  3. Ansonsten alle ElasticSearch-Dienste neu starten und die Protokolle prüfen. 


für Punkt 4: nicht genug RAM

  1. Wenn es nur der Java-RAM ist, über die ElasticSearch*w.exe den Speicher erhöhen.
  2. Ansonsten hilft nur RAM aufrüsten.  


für Punkt 5 und 6: Störungen/Netzwerkfehler/Plattenfehler/Daten kaputt ...

  1. Hier wäre wichtig zu wissen, welcher Fehler im Log und bei cluster/allocation ausgegeben wurde (http://127.0.01:8041/_cluster/allocation/explain?include_disk_info=true). 
    Am besten Indexservice und Searchservice außer Betrieb nehmen bis das Problem gefunden und gelöst wurde. Dazu in der servicewatcher-sw.yml die Instance für Index- und Searchservice je auf  0 stellen und dann die Konfiguration im Servicemanager neu laden, siehe Wie kann ich die geänderte Config im Servicemanager laden ohne Dienststart?. Es dauert meist etwas, bis Index- und Search entladen werden. 
  2. Fall Timeout: 
    1. Wenn die Daten zu groß sind, kann der Standardtimeout oder der eingestellt Timeout nicht mehr reichen. D.h. prüfen und ggfls. erhöhen.
      Timeout ermitteln:
      http://<elasticsearch-server>:8041/_settings 
      Bsp.: http://127.0.0.1:8041/_settings Dann im Ergebnis nach Timeout suchen.  
      Ist keine Timeout zu finden, dann gilt ElasticSearchstandard (5 Min.)
    2. Timeout auf 10 Min. setzen für alle Shards:
      PUT http://127.0.0.1:8041/_all/_settings
      {  "settings": {  "index.unassigned.node_left.delayed_timeout": "10m"   }  }
    3. Es lohnt sich, den Parameter zu prüfen (Timeout ermitteln). 
  3. Fall Netzwerkfehler/Kommunikationsfehler ...
    1. Ermitteln, welche Fehler es gibt, siehe auch https://www.elastic.co/guide/en/elasticsearch/reference/2.4/delayed-allocation.html:
      http://<elasticsearch-server>:8041/_cluster/allocation/explain?include_disk_info=true
    2. Am einfachsten das Reroute starten:
      einfaches Reroute, entspricht, einfach noch einmal versuchen: POST http://127.0.0.1:8041/_cluster/reroute
      Reroute mit Erzwingen, dass auch alle unassigned und fehlerhaft markierter Shards noch einmal neu geladen werden: POST http://127.0.01:8041/_cluster/reroute?retry_failed=true 

  4. Sollten die Daten kaputt sein, dann prüfen, ob in den Datenverzeichnissen Dateien liegen, die corrupt* heißen.

    1. Sofern welche gefunden werden: ElasticSearch beenden und die corrupt*-Dateien entfernen. 

    2. Dann den ElasticSearch neu starten. Es empfiehlt sich vorher die Logs des ElasticSearch zu entfernen. 
  5. Sofern der vorherige Punkt nicht geholfen haben sollte, kann man auch versuchen die Prüfung+Reparatur wie folgt vorzunehmen:
    1. ElasticSearch beenden. 
    2. Commandline / CMD als Admin starten 

    3. zum LIB-Verzeichnis im ElasticSearch wechseln:
      cd d:\enaio\services\elasticsearch\lib

    4. prüfen, wie die Lucene-core*.jar heißt 
      dir lucene-core*.jar 
      Den Namen notieren für den nächsten Befehl. Sind mehrere vorhanden, dann die höchste Nummer merken. 

    5. Nun die Prüfung+Reparatur starten (Beispiel mit lucene-core-8.0.0.jar). Dazu pro Eintrag (aus cluster/allocation - Node_id = Shard-ID) aufrufen, Beispiel für Shard mit der ID sAS8A4hbSb-RECk0ftvZFg:
      verbose = Prüfung, exorcise = Entfernen 
      java -cp lucene-core-8.0.0.jar -ea:org.apache.lucene… org.apache.lucene.index.CheckIndex c:\enaiodata\Elasticsearch\nodes\0\indices\sAS8A4hbSb-RECk0ftvZFg\0\index -verbose -exorcise


    6. Nun wird dieser Shard physisch geprüft. Kaputte Einträge werden entfernt. Manchmal bleiben corrupt* Dateien liegen. Diese müssen entfernt werden. 
    7. ElasticSearch starten und prüfen, ob es nun funktioniert 


für Punkt 7: Das Laden dauert einfach nur lange

  1. Hier hilft nur abwarten. Langfristig kann man sich überlegen, ob die Shards gesplittet werden sollten,  siehe: ElasticSearch - Splitten / Resharding. 
  2. Bei diesem Link kann man sehen, ob die Daten noch am Laden sind (alle Spalten müssen 100% haben):
    http://<elasticsearch-server>:8041/_cat/recovery?v 
    Bsp.: http://127.0.0.1:8041/_cat/recovery?v


für Punkt 8: Volltext-Daten irreparabel

  1. Sollten es "nur" die Replicas sein, kann man auch die Replikation abschalten, siehe Fehlerfall 2 (Replicas aktiviert bei 1 ElasticSearch-Server). Die Replica-Shards werden automatisch gelöscht, egal ob unassigned oder nicht. Sobald das durch ist, die Replikation wieder aktivieren. 
  2. Ansonsten hilft nur Volltext neu aufbauen. Da ab enaio 9.10 ein Passwort hinterlegt ist, sollte man sich überlegen, ob man die komplette Volltextdatenbank löscht oder besser die betroffenen Shards löscht. Vorgehen analog: Wie kann man den Volltext beim Update migrieren? Welche Szenarien gibt es zum Vervollständigen?


für Punkt 9: Fehler in den Transaktionslogs

siehe auch https://www.elastic.co/guide/en/elasticsearch/reference/7.17/shard-tool.html
Wichtig: alle Documente bzw. Objecte, die in diesen kaputten Transaktionslogs liegen, fehlen im Volltext. Aktuell haben wir noch nichts gefunden, wie man herausbekommt, welche Object-IDs (enaio-IDs) es betrifft. D.h. eine Volltextprüfung bzw. NewIndexing sollte nach der Reparatur und Abarbeitung der CPQueue erfolgen, siehe Punk "Kurzform für nachträgliche Aktivierung Volltext" bei Wie kann man den Volltext beim Update migrieren? Welche Szenarien gibt es zum Vervollständigen?
Wenn im Log oder bei einer Abfrage diese Meldung kommt, hilft die nachfolgende Anleitung:
"Caused by: org.elasticsearch.index.translog.TranslogCorruptedException: translog from source [D:\OSECM\OS_Daten\OS_Fulltext\Elasticsearch7-Data\nodes\0\indices\Ut3ZiJ6OSK--_b6_I_6vTA\3\translog\translog-12230.ckp] is corrupted"

  1. Ermitteln, bei welchem Shard die Transaktionslogs nicht geladen werden können auf welcher Node und die Node-ID. Dazu dies aufrufen: 
    1. Shard ermitteln ("_cluster" geht auch bei nur 1 Instanz/ElasticSearch-Server):
      http://<elasticsearch-server>:8041/_cluster/allocation/explain?include_disk_info=true
      Bsp.: http://127.0.0.1:8041/_cluster/allocation/explain?include_disk_info=true
    2. Node-ID ermitteln: 
      http://127.0.0.1:8041/_cluster/state
      Im Ergebnis den Node-Name heraussuchen, auf dem der kaputte Shard liegt. Beispiel für os-fulltext-1:
  2. ElasticSearch-Dienst(e) beenden.
  3. CMD explizit "als Administrator ausführen" aufrufen und in das ElasticSearch\Bin-Verzeichnis wechseln 
  4. Diesen Befehl eingeben: 
    elasticsearch-shard remove-corrupted-data --index <shard> --shard-id <shardid> --truncate-clean-translog
    Beispiel: Transaktionslogs des Autocomplete Shard 0 sind kaputt:
    elasticsearch-shard remove-corrupted-data --index autocomplete_0 --shard-id 0 --truncate-clean-translog
  5. Die Sicherheitsabfrage mit Y bestätigen (man muss bestätigen, dass man wirklich Daten löschen möchte). 
  6. Nun abwarten, bis die Reparatur erledigt ist. Es wird ein neuer Shard erstellt mit den Daten, die gerettet werden können. Die ID bitte notieren für spätere Kontrolle. 
  7. ElasticSearch starten. Der Shard wird noch auf unassigned stehen bleiben, da der neue Shard erst bekannt gemacht werden muss.
  8. Den reparierten Shard aktivieren, entweder per Curl oder per API-Tool (z. Bsp. Postman):
    Beim Curl-Befehl daran denken, dass Benutzer+Passwort mitgegeben werden müssen. 
    POST http://<elasticsearch-server>:8041/_cluster/reroute 
    { "commands" : [ { "allocate_stale_primary" : { "index" : "<shard>", "shard" : <neue shard-id>, "node" : "<nodename>", "accept_data_loss" : true } } ] }

    Beispiel für Autocomplete_0 Shard-ID 0, neue ID aus Punkt 6: 
    POST http://127.0.0.1:8041/_cluster/reroute 
    { "commands" : [ { "allocate_stale_primary" : { "index" : "autocomplete_0", "shard" : 0, "node" : "hGtilfflS72JfhM0rwxSWQ", "accept_data_loss" : true } } ] }

    Beispiel-Curl-Aufruf:
    curl -X POST --header "Content-Type: application/json" --header "Accept: */*" -d "{\"commands\": [ {\"allocate_stale_primary\": {\"index\": \"autocomplete_0\",\"shard\" : 0,\"node\" : \"hGtilfflS72JfhM0rwxSWQ\",\"accept_data_loss\" : true}}]} " "http://127.0.0.1:8041/_cluster/reroute" --user elastic:MncxzNr1kE4MaWOkTVTn
  9. abwarten, bis der Vorgang beendet ist und Kontrolle, ob alle Shards geladen werden: 
    http://<elasticsearch-server>:8041/_cat/shards?v 
    Bsp.: http://127.0.0.1:8041/_cat/shards?v
    Status während des Ladens: 
    http://<elasticsearch-server>:8041/_cat/recovery?v 
    Bsp.: http://127.0.0.1:8041/_cat/recovery?v


für Punkt 10: es gibt corrupt* Dateien. 

Solange in einem Datenverzeichnis eine corrupt-Datei liegt, gilt der Shard als nicht exitent und wird nicht geladen. 

  1. ElasticSearch-Dienst beenden. 
  2. Im Datenverzeichnis nach corrupt* suchen 
  3. Die Dateien verschieben oder in den Windows-Papierkorb schieben (löschen, nicht endgültig löschen)
  4. Logs des ElasticSearch entfernen. 
  5. ElasticSearch-Dienst starten. 
  6. Über die URLs Shards prüfen, ob nun alles geladen wird und - falls das Laden länger dauert - über recovery, wie weit es kommt.
    http://<elasticsearch-server>:8041/_cat/shards?v 
    Bsp.: http://127.0.0.1:8041/_cat/shards?v
    Status während des Ladens: 
    http://<elasticsearch-server>:8041/_cat/recovery?v 
    Bsp.: http://127.0.0.1:8041/_cat/recovery?v


für Punkt 11: eine Lock-Datei ist defekt und kann nicht geladen werden. 

Diese Aktion bzw. die nachfolgenden Schritte sind mit Vorsicht zu genießen, da es vorkommen kann, dass die ElasticSearch-Datenbank danach kaputt ist oder nicht korrekt geladen werden kann. 

  1. ElasticSearch-Dienst beenden. 
  2. das Datenverzeichnis nach write.lock durchsuchen. 
  3. Alle gefundenen Daten entfernen, am besten in den Windows-Papierkorb schieben (löschen, nicht endgültig löschen)
  4. ElasticSearch-Dienst starten. 
  5. Über die URLs Shards prüfen, ob nun alles geladen wird und - falls das Laden länger dauert - über recovery, wie weit es kommt.
    http://<elasticsearch-server>:8041/_cat/shards?v 
    Bsp.: http://127.0.0.1:8041/_cat/shards?v
    Status während des Ladens: 
    http://<elasticsearch-server>:8041/_cat/recovery?v 
    Bsp.: http://127.0.0.1:8041/_cat/recovery?v


Die Protokolle geben im allgemeinen Hinweise, was für Fehler aufgetreten sind. Man kann auch im Internet nach Foren suchen und bekommt oftmals hilfreiche Informationen. 

Verwandte Artikel