Возвращение ноды в кластер после аварии и таймауты "all shards failed"

[Sergei_Frolov]

Добрый день!

Произошла неприятная ситуация - из-за перегрева процессора (криво собранный сервер) вышла нода из строя (всего нод 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

[Igor_Motov]

Когда узел стартует и обнаруживает у себя на диске шарды, он начинает проверять их целостность и сверять на сколько эти шарды устарели по сравнению с другими шардами в кластере, и если надо, то синхронизировать их с шардами на других узлах. Этот процесс называется recovery и может оказывать значительную нагрузку на узел, что может, в свою очередь, привести к уменьшению производительности кластера для других операций. Например, это может значительно увеличить время поиска и вызывать таймауты.

Для того что бы снизить эту нагрузку elasticsearch по умолчанию "дросселирует" процесс recovery. В некоторых случаях, когда желательно скорейшее восстановление кластера за счет увеличения времени все остальных операций, можно это дросселирование уменьшить увеличением значений параметров отвечающих за скорость и параллельность процесса recovery, что вы в этом кластере и сделали.

[Sergei_Frolov]

Игорь, спасибо за ответ!

То есть все что можно было сделать, все сделано?

Добавление еще нескольких нод сможет помочь? В приложении все ноды, к которому это приложение обращается, перечислены массивом. Очень не хотелось бы получать таймауты сервиса.

Заодно скажите пожалуйста - когда ноды кластера перечислены массивом в приложении - эластик отвечает на запросы и индексирует параллельно, или раунд-робином? Может ли он отвечать на запросы и индексировать и параллельно, и раунд-робином?

[Igor_Motov]

@Sergei_Frolov

То есть все что можно было сделать, все сделано?

Наверное, я плохо объяснил. То что было сделано, скорее всего, как раз и привело к полученному результату. Вам надо решить, что вам важнее - ускорение recovery или стабильный поиск. Если стабильный поиск - то я бы начал, с возврата к значениям по умолчанию для indices.recovery.max_bytes_per_sec и cluster.allocation.node_cuncurrent_recoveries.

@Sergei_Frolov

Заодно скажите пожалуйста - когда ноды кластера перечислены массивом в приложении - эластик отвечает на запросы и индексирует параллельно, или раунд-робином? Может ли он отвечать на запросы и индексировать и параллельно, и раунд-робином?

Elasticsearch отвечает на все запросы параллельно если ему хватает потоков. Как ваше приложение посылает запросы в elasticsearch я не знаю.