Mam klaster ES z 4 węzłami:
number_of_replicas: 1
search01 - master: false, data: false
search02 - master: true, data: true
search03 - master: false, data: true
search04 - master: false, data: true
Musiałem ponownie uruchomić search03, a kiedy wrócił, bez problemu połączył się z klastrem, ale zostawił 7 nieprzypisanych fragmentów.
{
"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
}
Teraz moja gromada jest w stanie żółtym. Jaki jest najlepszy sposób rozwiązania tego problemu?
- Usunąć (anulować) fragmenty?
- Przenieść fragmenty do innego węzła?
- Przydzielić fragmenty do węzła?
- Zaktualizować „number_of_replicas” do 2?
- Coś zupełnie innego?
Co ciekawe, kiedy dodano nowy indeks, ten węzeł zaczął nad nim pracować i grał dobrze z resztą klastra, po prostu zostawiał nieprzypisane fragmenty.
Przejdź do pytania: czy w ogóle robię coś złego, aby tak się stało? Nie mam zaufania do klastra, który zachowuje się w ten sposób po ponownym uruchomieniu węzła.
UWAGA: Jeśli z jakiegoś powodu używasz klastra z jednym węzłem, możesz po prostu wykonać następujące czynności:
curl -XPUT 'localhost:9200/_settings' -d '
{
"index" : {
"number_of_replicas" : 0
}
}'
źródło
{ "error" : "ElasticsearchIllegalArgumentException[[allocate] failed to find [logstash-2015.01.05][1] on the list of unassigned shards]", "status" : 400 }
Mimo że widzę, że fragment jest jednym z nieprzydzielonych w ES-Head-H 'Content-Type: application/json'
jeśliContent-Type header [application/x-www-form-urlencoded] is not supported
OK, rozwiązałem ten problem z pomocą pomocy technicznej ES. Wydaj następujące polecenie do interfejsu API na wszystkich węzłach (lub węzłach, które Twoim zdaniem są przyczyną problemu):
gdzie
<index>
jest indeks, który Twoim zdaniem jest winowajcą. Jeśli nie masz pojęcia, po prostu uruchom to na wszystkich węzłach:Dodałem również tę linię do mojej konfiguracji yaml i od tego czasu wszelkie ponowne uruchomienia serwera / usługi były bezproblemowe. Odłamki natychmiast ponownie przydzielone.
FWIW, aby odpowiedzieć na często poszukiwane pytanie, ustaw MAX_HEAP_SIZE na 30G, chyba że twoja maszyna ma mniej niż 60G RAM, w takim przypadku ustaw ją na połowę dostępnej pamięci.
Bibliografia
źródło
index.routing.allocation.disable_allocation : false cluster.routing.allocation.enable: none
Ale nadal pojawiają się nieprzypisane odłamki… Jaki może być tego powód?{ "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" } ],
Ten mały skrypt basha brutalnie wymusi ponowne przypisanie, możesz stracić dane.
źródło
{"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}
Jedyną rzeczą, która działała dla mnie, była zmiana number_of_replicas (miałem 2 repliki, więc zmieniłem to na 1, a następnie zmieniłem z powrotem na 2).
Pierwszy:
Następnie:
(Już odpowiedziałem na to pytanie )
źródło
Elasticsearch automatycznie przydziela shardy, jeśli poniższa konfiguracja jest ustawiona na all. Tę konfigurację można ustawić również za pomocą interfejsu API REST, a także cluster.routing.allocation.enable: all
Jeśli nawet po zastosowaniu poniższej konfiguracji, es nie przypisze fragmentów automatycznie, musisz samodzielnie wymusić przypisanie fragmentów. Oficjalny link ES do tego
Napisałem skrypt, który wymusza przypisanie wszystkich nieprzypisanych fragmentów w klastrze.
Poniższa tablica zawiera listę węzłów, wśród których chcesz zrównoważyć nieprzypisane fragmenty
źródło
Utknąłem dzisiaj z tą samą kwestią alokacji odłamków. Scenariusz, który zaproponował w swojej odpowiedzi W.Andrew Loe III, nie zadziałał, więc trochę go zmodyfikowałem i wreszcie zadziałał:
Nie jestem w pewnym sensie guru Bash, ale scenariusz naprawdę zadziałał w moim przypadku. Pamiętaj, że musisz określić odpowiednie wartości dla zmiennych „ES_HOST” i „NODE”.
źródło
allocate
zallocate_empty_primary
i wymienić\"allow_primary\": true
z\"accept_data_loss\": true
{"error":"Content-Type header [application/x-www-form-urlencoded] is not supported","status":406}
nawet po zastosowaniu sugestiiW moim przypadku górna granica miejsca na dysku została osiągnięta.
Spójrz na ten artykuł: https://www.elastic.co/guide/en/elasticsearch/reference/current/disk-allocator.html
Zasadniczo pobiegłem:
Aby przydzielił, jeśli jest używane <90% miejsca na dysku twardym, i przeniesie fragment na inny komputer w klastrze, jeśli> 95% zajętego miejsca na dysku twardym; i sprawdza co 1 minutę.
źródło
Może to komuś pomoże, ale miałem ten sam problem i wynikał z braku miejsca na przechowywanie spowodowanego zbyt dużym kłodą.
Mam nadzieję, że to komuś pomoże! :)
źródło
W moim przypadku, kiedy tworzę nowy indeks, domyślna liczba_replik jest ustawiana na 1. A liczba węzłów w moim klastrze była tylko jeden, więc nie było dodatkowego węzła do utworzenia repliki, więc stan zdrowia zmienił się na żółty. Więc kiedy utworzyłem indeks z właściwością settings i ustawiłem number_of_replicas na 0. Wtedy zadziałało dobrze. Mam nadzieję że to pomoże.
źródło
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.routing.allocation.disable_allocation” na false i ustawienie „cluster.routing.allocation.enable” na „all”) nie zadziałały.
Jednak odpowiedź @Wilfred Hughes (ustawienie „cluster.routing.allocation.enable” na „all” przy użyciu transient) dała mi błąd z następującym stwierdzeniem:
Po zaktualizowaniu starych węzłów do wersji 1.4.4, te węzły zaczęły ponownie współdziałać z innymi dobrymi węzłami.
źródło
Miałem również ten problem i znalazłem łatwy sposób na jego rozwiązanie.
Uzyskaj indeks nieprzypisanych fragmentów
Zainstaluj narzędzia kuratora i użyj ich do usunięcia indeksu
UWAGA: W moim przypadku indeksem jest logstash z dnia 21.04.2016
źródło
curator_cli --host 127.0.0.1 delete_indices --filter_list '[{"filtertype":"pattern","kind":"prefix","value":"logstash-"}]'
Ja też spotykam się z tą sytuacją i ostatecznie ją naprawiłem.
Najpierw opiszę swoją sytuację. Mam dwa węzły w klastrze ElasticSearch, mogą się one 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 pojawia się, ponieważ wartość number_of_replicas , kiedy ustawię jej wartość na 1 , wszystko jest w porządku.
źródło
W moim przypadku do klastra dołączał stary węzeł ze starymi udziałami, więc musieliśmy zamknąć stary węzeł i usunąć indeksy z nieprzypisanymi fragmentami.
źródło
Wypróbowałem kilka z powyższych sugestii i niestety żadna z nich nie zadziałała. Mamy indeks „Log” w naszym niższym środowisku, w którym aplikacje zapisują swoje błędy. Jest to klaster z jednym węzłem. Rozwiązaniem tego problemu było sprawdzenie pliku konfiguracyjnego YML dla węzła i stwierdzenie, że nadal ma on domyślne ustawienie „gateway.expected_nodes: 2”. To przesłaniało wszelkie inne ustawienia, które mieliśmy. Za każdym razem, gdy utworzylibyśmy indeks w tym węźle, spróbowalibyśmy rozłożyć 3 z 5 fragmentów do drugiego węzła fantomowego. W związku z tym wyglądałyby one jako nieprzypisane i nigdy nie można ich było przenieść do pierwszego i jedynego węzła.
Rozwiązaniem była edycja konfiguracji, zmiana ustawienia „gateway.expected_nodes” na 1, tak aby przestał szukać swojego nieodnalezionego brata w klastrze i zrestartował instancję usługi Elastic. Musiałem też usunąć indeks i utworzyć nowy. Po utworzeniu indeksu wszystkie fragmenty pojawiły się w pierwszym i jedynym węźle i żaden nie był nieprzypisany.
źródło
W moim przypadku problem został rozwiązany, uruchamiając to z konsoli programisty: „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łem
"get /_cat/shards?h=[INDEXNAME],shard,prirep,state,unassigned.reason"
i zobaczył, że fragmenty utknęły w stanie ALLOCATION_FAILED, więc wykonanie powyższej ponownej próby spowodowało ponowne wypróbowanie alokacji.
źródło
Może pomóc, ale miałem ten problem podczas próby uruchomienia ES w trybie osadzonym. Poprawka polegała na upewnieniu się, że Węzeł miał ustawiony lokalny (true).
źródło
Innym możliwym powodem nieprzypisanych fragmentów jest to, że w klastrze działa więcej niż jedna wersja pliku binarnego Elasticsearch.
Może to być główną przyczyną nieprzypisanych fragmentów.
Elastyczna dokumentacja - stopniowy proces aktualizacji
źródło
Napotkałem dokładnie ten sam problem. Można temu zapobiec, tymczasowo ustawiając alokację fragmentu na wartość false przed ponownym uruchomieniem elastycznego wyszukiwania, ale nie naprawia to nieprzypisanych fragmentów, jeśli już tam są.
W moim przypadku było to spowodowane brakiem wolnego miejsca na dysku w węźle danych. Nieprzypisane fragmenty nadal znajdowały się w węźle danych po ponownym uruchomieniu, ale nie zostały rozpoznane przez master.
Już samo wyczyszczenie 1 węzłów z dysku spowodowało rozpoczęcie procesu replikacji. Jest to raczej powolny proces, ponieważ wszystkie dane muszą zostać skopiowane z jednego węzła danych do drugiego.
źródło
Próbowałem usunąć nieprzypisane fragmenty lub ręcznie przypisać je do konkretnego węzła danych. To nie zadziałało, ponieważ ciągle pojawiały się nieprzypisane odłamki, a stan zdrowia był „czerwony” w kółko. Potem zauważyłem, że jeden z węzłów danych utknął w stanie „restartu”. Zmniejszyłem liczbę węzłów danych, zabiłem to. Problem nie jest już odtwarzalny.
źródło
Miałem dwa indeksy z nieprzypisanymi odłamkami, które nie wyglądały na samoleczące. Ostatecznie rozwiązałem ten problem, dodając tymczasowo dodatkowy węzeł danych [1] . Po tym, jak wskaźniki stały się zdrowe i wszystko ustabilizowało się na zielono, usunąłem dodatkowy węzeł i system był w stanie ponownie zrównoważyć (ponownie) i ustabilizować się w zdrowym stanie.
Dobrym pomysłem jest unikanie zabijania wielu węzłów danych na raz (w ten sposób doszedłem do tego stanu). Prawdopodobnie nie udało mi się zachować żadnych kopii / replik co najmniej jednego z odłamków. Na szczęście Kubernetes zachował miejsce na dysku i użył go ponownie, gdy ponownie uruchomiłem węzeł danych.
...Minęło trochę czasu...
Cóż, tym razem samo dodanie węzła nie działało (po kilku minutach oczekiwania, aż coś się wydarzy), więc zacząłem grzebać w REST API.
To pokazało mój nowy węzeł z
"decision": "YES"
.Nawiasem mówiąc, wszystkie wcześniej istniejące węzły miały
"decision": "NO"
skutek"the node is above the low watermark cluster setting"
. Więc to był prawdopodobnie inny przypadek niż ten, o którym mówiłem wcześniej.Następnie wykonałem następujący prosty POST [2] bez ciała , co wprawiło wszystko w ruch ...
Inne notatki:
Bardzo pomocne: https://datadoghq.com/blog/elasticsearch-unassigned-shards
Coś innego, co może działać. Ustaw
cluster_concurrent_rebalance
się0
, a potemnull
- jak wykazać tutaj .[1] Całkiem łatwe do zrobienia w Kubernetes, jeśli masz wystarczający zapas: po prostu wyskaluj zestaw stanowy za pomocą pulpitu nawigacyjnego.
[2] Używając interfejsu Kibana "Dev Tools", nie musiałem zawracać sobie głowy powłokami SSH / exec.
źródło
Po prostu najpierw zwiększyłem
o 1 (poczekaj, aż węzły zostaną zsynchronizowane), a następnie zmniejsz go o 1, co skutecznie usuwa nieprzypisane fragmenty i klaster jest ponownie zielony bez ryzyka utraty jakichkolwiek danych.
Wierzę, że są lepsze sposoby, ale to jest dla mnie łatwiejsze.
Mam nadzieję że to pomoże.
źródło
W przypadku uszkodzonych fragmentów można ustawić współczynnik replikacji na 0, a następnie przywrócić pierwotną wartość. Powinno to usunąć większość, jeśli nie wszystkie, uszkodzone fragmenty i przenieść nowe repliki w klastrze.
Ustawianie indeksów z nieprzypisanymi replikami, aby używały współczynnika replikacji równego 0:
Ustawiam je z powrotem na 1:
Uwaga: nie uruchamiaj tego, jeśli masz różne współczynniki replikacji dla różnych indeksów. Spowodowałoby to utrwalenie współczynnika replikacji dla wszystkich indeksów na 1.
źródło