# Возвращение ноды в кластер после аварии и таймауты "all shards failed"
**URL:** https://discuss.elastic.co/t/all-shards-failed/243326
**Category:** Вопросы на русском языке
**Created:** [July 31, 2020, 8:52am UTC](https://discuss.elastic.co/t/all-shards-failed/243326 "2020-07-31T08:52:12Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Sergei\_Frolov](https://discuss.elastic.co/u/Sergei_Frolov)
#### Post date: [July 31, 2020, 8:52am UTC](https://discuss.elastic.co/t/all-shards-failed/243326/1 "2020-07-31T08:52:12Z")
Добрый день!
Произошла неприятная ситуация - из-за перегрева процессора (криво собранный сервер) вышла нода из строя (всего нод 5, в строю осталось 4 соответственно). Примерно через час была возвращена - но сервис постоянно таймаутил в этот момент (в момент возвращения ноды). Я так понимаю что шарды начали синхронизироваться (разъезжаться) - и сервис обращаясь к ним получал таймаут.
В логах в это время было:
```
[2020-07-31T11:02:12,048][WARN][r.suppressed] [node1.ru] path: /indexname/_search, params: {pretty=true, index=indexname}
org.elasticsearch.action.search.SearchPhaseExecutionException: all shards failed
at org.elasticsearch.action.search.AbstractSearchAsyncAction.onPhaseFailure(AbstractSearchAsyncAction.java:551) [elasticsearch-7.8.0.jar:7.8.0]
...
Caused by: org.elasticsearch.tasks.TaskCancelledException: The parent task was cancelled, shouldn't start any child tasks
```
Подскажите, как сделать этот процесс возвращения ноды в кластер наиболее "прозрачным", чтобы сервис не таймаутил? Возможно ли это?
Для более быстрого восстановления я еще при создании кластера поменял некоторые настройка кластера, но это не помогло в сегодняшней проблеме. Сейчас настройки такие:
```
{
"persistent" : {
"cluster" : {
"routing" : {
"allocation" : {
"node_concurrent_recoveries" : "50"
}
}
},
"indices" : {
"recovery" : {
"max_bytes_per_sec" : "2500mb"
}
},
"xpack" : {
"monitoring" : {
"collection" : {
"enabled" : "true"
}
}
}
},
"transient" : { }
}
```
Версия 7.8.0
---
### Author:  [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)
#### Post date: [July 31, 2020, 1:30pm UTC](https://discuss.elastic.co/t/all-shards-failed/243326/2 "2020-07-31T13:30:07Z")
Когда узел стартует и обнаруживает у себя на диске шарды, он начинает проверять их целостность и сверять на сколько эти шарды устарели по сравнению с другими шардами в кластере, и если надо, то синхронизировать их с шардами на других узлах. Этот процесс называется recovery и может оказывать значительную нагрузку на узел, что может, в свою очередь, привести к уменьшению производительности кластера для других операций. Например, это может значительно увеличить время поиска и вызывать таймауты.
Для того что бы снизить эту нагрузку elasticsearch по умолчанию "дросселирует" процесс recovery. В некоторых случаях, когда желательно скорейшее восстановление кластера за счет увеличения времени все остальных операций, можно это дросселирование уменьшить увеличением значений параметров отвечающих за скорость и параллельность процесса recovery, что вы в этом кластере и сделали.
---
### Author:  [@Sergei\_Frolov](https://discuss.elastic.co/u/Sergei_Frolov)
#### Post date: [July 31, 2020, 1:40pm UTC](https://discuss.elastic.co/t/all-shards-failed/243326/3 "2020-07-31T13:40:59Z")
Игорь, спасибо за ответ!
То есть все что можно было сделать, все сделано? 🙂
Добавление еще нескольких нод сможет помочь? В приложении все ноды, к которому это приложение обращается, перечислены массивом. Очень не хотелось бы получать таймауты сервиса.
Заодно скажите пожалуйста - когда ноды кластера перечислены массивом в приложении - эластик отвечает на запросы и индексирует параллельно, или раунд-робином? Может ли он отвечать на запросы и индексировать и параллельно, и раунд-робином?
---
### Author:  [@Igor\_Motov](https://discuss.elastic.co/u/Igor_Motov)
#### Post date: [July 31, 2020, 2:21pm UTC](https://discuss.elastic.co/t/all-shards-failed/243326/4 "2020-07-31T14:21:16Z")
> [@Sergei\_Frolov](#):
>
> То есть все что можно было сделать, все сделано? 🙂
Наверное, я плохо объяснил. То что было сделано, скорее всего, как раз и привело к полученному результату. Вам надо решить, что вам важнее - ускорение recovery или стабильный поиск. Если стабильный поиск - то я бы начал, с возврата к значениям по умолчанию для `indices.recovery.max_bytes_per_sec` и `cluster.allocation.node_cuncurrent_recoveries`.
> [@Sergei\_Frolov](#):
>
> Заодно скажите пожалуйста - когда ноды кластера перечислены массивом в приложении - эластик отвечает на запросы и индексирует параллельно, или раунд-робином? Может ли он отвечать на запросы и индексировать и параллельно, и раунд-робином?
Elasticsearch отвечает на все запросы параллельно если ему хватает потоков. Как ваше приложение посылает запросы в elasticsearch я не знаю.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [August 28, 2020, 2:21pm UTC](https://discuss.elastic.co/t/all-shards-failed/243326/5 "2020-08-28T14:21:17Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.