ElasticSearch: Nieprzypisane odłamki, jak naprawić?

Domyślnie Elasticsearch ponownie przydziela odłamki do węzłów dynamicznie. Jeśli jednak wyłączyłeś przydzielanie shard (być może wykonałeś (aś) rolling restart i zapomniałeś go ponownie włączyć), możesz ponownie włączyć przydzielanie shard.

# 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 ponownie przypisze odłamki jak zwykle. Może to być powolne, rozważ podnoszenie indices.recovery.max_bytes_per_sec i cluster.routing.allocation.node_concurrent_recoveries, aby przyspieszyć.

Jeśli nadal widzisz problemy, prawdopodobnie coś innego jest nie tak, więc zajrzyj do dzienników Elasticsearch pod kątem błędów. Jeśli Zobacz EsRejectedExecutionException twoje pule wątków mogą być zbyt małe .

Wreszcie, możesz jawnie przypisać odłamek do węzła za pomocą reroute API.

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

Ten mały skrypt Basha brutalnie zmieni przypisanie, możesz stracić dane.

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

Jedyne co mi się udało to zmiana number_of_replicas(miałem 2 repliki, więc zmieniłem na 1, a potem z powrotem na 2).

Pierwszy:

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

Wtedy:

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

(już w to pytanie )

Elasticsearch automatycznie przydziela odłamki, jeśli poniższa konfiguracja jest ustawiona na all. Tę konfigurację można ustawić również za pomocą rest api Gromada./ align = "left" / przydział.enable: all

Jeśli nawet po zastosowaniu poniższej konfiguracji es Nie przypisze odłamków automatycznie, musisz wymusić przypisanie odłamków samodzielnie. ES oficjalny link do tego

Napisałem skrypt, aby wymusić przypisanie wszystkich nieprzypisanych odłamków w całym klastrze.

Poniżej tablica zawiera listę węzłów, wśród których chcesz zrównoważyć nieprzypisane odłamki

#!/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

Utknąłem dzisiaj z tym samym problemem przydziału odłamków. Scenariusz, który W. Andrew Loe III zaproponował w swojej odpowiedzi nie działa dla mnie, więc zmodyfikowałem go trochę i w końcu zadziałał:

#!/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

W moim przypadku osiągnięto górną granicę miejsca na dysku twardym.

Spójrz na ten artykuł: https://www.elastic.co/guide/en/elasticsearch/reference/current/disk-allocator.html

W zasadzie biegłem:

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

, aby przydzielić 95% używanego miejsca na dysku twardym; i sprawdza co 1 minutę.

Może komuś to pomaga, ale ja miałem ten sam problem i był on spowodowany brakiem miejsca na dysku spowodowanym zbyt dużym logiem.

Mam nadzieję, że komuś pomoże! :)

Miałem ten sam problem, ale główną przyczyną była różnica w numerach wersji (1.4.2 na dwóch węzłach (z problemami) i 1.4.4 na dwóch węzłach (ok)). Pierwsza i druga odpowiedź (ustawienie " index./ align = "left" / przydział.disable_allocation "to false and setting" cluster./ align = "left" / przydział.enable" to "all") nie działa.

Jednak odpowiedź przez @ Wilfred Hughes (ustawienie " cluster./ align = "left" / przydział.enable " to " all " using transient) dał mi błąd z następującą instrukcją:

[NO (wersja węzła docelowego [1.4.2] jest starsza niż wersja węzła źródłowego [1.4.4])]

Po aktualizacji starych węzłów do 1.4.4 węzły te zaczęły resnc z innymi dobrymi węzłami.

Ja też miałem ten problem i znalazłem łatwy sposób na jego rozwiązanie.

• Get the index of unassigned shards

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

• Zainstaluj narzędzia kuratora i użyj ich do usunięcia indeksu

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

  Uwaga: w moim przypadku indeks jest logstash dnia 2016-04-21

• potem sprawdź ponownie odłamki, wszystkie nieprzypisane odłamki znikną!

W moim przypadku, kiedy tworzę nowy indeks wtedy domyślna number_of_replicas jest ustawiona jako 1. A liczba węzłów w moim klastrze była tylko jedna, więc nie było dodatkowego węzła do tworzenia repliki, więc zdrowie zmieniało się na żółte. Więc kiedy stworzyłem Indeks z ustawienia właściwość i ustaw number_of_replicas jako 0. Potem działało dobrze. Mam nadzieję, że to pomoże.

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

Również spotykam się z tą sytuacją i w końcu ją naprawiam.

Najpierw opiszę moją sytuację. Mam dwa węzły w klastrze ElasticSearch, mogą się znaleźć, ale kiedy utworzyłem Indeks z ustawieniami "number_of_replicas" : 2, "number_of_shards": 5, ES pokazuje Żółty sygnał, a unassigned_shards to 5.

Problem występuje ponieważ wartość number_of_replicas, kiedy ustawiam jej wartość z 1, wszystko w porządku.

W moim przypadku Stary węzeł ze starymi udziałami dołączał do klastra, więc musieliśmy zamknąć Stary węzeł i usunąć indeksy z nieprzypisanymi odłamkami.

Dla mnie to zostało rozwiązane poprzez uruchomienie tego z konsoli dev: "POST/_cluster / reroute?retry_failed "

.....

Zacząłem od spojrzenia na listę indeksów, aby zobaczyć, które indeksy były czerwone, a następnie uruchomił

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

I zobaczyłem, że odłamki utknęły w stanie ALLOCATION_FAILED, więc uruchomienie powyższej ponownej próby spowodowało, że ponownie spróbowali alokacji.

Może pomóc, ale miałem ten problem podczas próby uruchomienia ES w trybie embedded. Poprawka polegała na upewnieniu się, że węzeł ma ustawiony lokalny(true).

Innym możliwym powodem nieprzypisanych odłamków jest to, że Twój klaster działa więcej niż jedna Wersja pliku binarnego Elasticsearch.

Replikacja Shard z nowszej wersji do poprzedniej wersje nie będą działać

To może być główna przyczyna dla nieprzypisanych odłamków.

Elastic Documentation-Rolling Upgrade Process

Natknąłem się na dokładnie ten sam problem. Można temu zapobiec, tymczasowo ustawiając przydział odłamków na false przed ponownym uruchomieniem elasticsearch, ale to nie naprawia nieprzypisanych odłamków, jeśli już tam są.

W moim przypadku było to spowodowane brakiem wolnego miejsca na dysku w węźle danych. Nieprzypisane odłamki, gdzie nadal na węźle danych po ponownym uruchomieniu, ale gdzie nie są rozpoznawane przez mistrza.

Po prostu czyszczenie 1 z węzłów z dysku uzyskało proces replikacji zaczęło się dla mnie. Jest to dość powolny proces, ponieważ wszystkie dane muszą być kopiowane z jednego węzła danych do drugiego.

Wypróbowałem kilka z powyższych sugestii i niestety żadna z nich nie zadziałała. W naszym dolnym środowisku mamy indeks "Log", w którym aplikacje zapisują swoje błędy. Jest to klaster pojedynczego węzła. To, co mnie rozwiązało, to sprawdzenie pliku konfiguracyjnego YML dla węzła i zobaczenie, że nadal ma domyślne ustawienie " gateway.expected_nodes: 2". To było nadpisanie wszystkich innych ustawień, które mieliśmy. Ilekroć tworzymy indeks na tym węźle, próbowalibyśmy rozłożyć 3 z 5 odłamków na widmo Drugi węzeł. W związku z tym będą one wyglądały jako nieprzypisane i nigdy nie będą mogły zostać przeniesione do pierwszego i jedynego węzła.

Rozwiązaniem była edycja config, zmiana ustawienia " gateway.expected_nodes " do 1, więc przestanie szukać swojego nigdy nie znalezionego brata w klastrze i ponownie uruchomi Elastic service instance. Musiałem również usunąć indeks i utworzyć nowy. Po utworzeniu indeksu wszystkie odłamki pojawiły się na pierwszym i jedynym węźle, a żaden nie był bez przydziału.

# 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

Próbowałem usunąć nieprzypisane odłamki lub ręcznie przypisać je do konkretnego węzła danych. Nie udało się, ponieważ nieprzypisane odłamki ciągle pojawiały się, a stan zdrowia był" czerwony " w kółko. Potem zauważyłem, że jeden z węzłów danych utknął w stanie "restart". Zmniejszyłem liczbę węzłów danych, zabiłem je. Problem nie jest już powtarzalny.