В Elasticsearch под восстановлением понимается процесс восстановления шарда, когда что-то пошло не так. Восстановление шардов может происходить при различных обстоятельствах, например, при отказе узла и необходимости создания реплики шарда из основного шарда, при необходимости перемещения шардов на разные узлы кластера в результате ребалансировки или изменения настроек распределения шардов, а также при восстановлении индекса из моментального снимка Elasticsearch. Кроме того, иногда Elasticsearch может выполнять восстановление автоматически, например, при перезагрузке узла или при его отключении и повторном подключении.
В целом, восстановление может происходить в следующих сценариях:
- Запуск или отказ узла (восстановление локального хранилища)
- Репликация первичных шардов на реплики
- Перемещение шарда на другой узел в том же кластере
- Восстановление моментального снимка
Планируемый перезапуск узла
Если планируется перезапуск узла, то для ускорения восстановления шардов после перезапуска узла можно предпринять некоторые действия. Для достижения оптимальной скорости восстановления необходимо остановить индексирование шардов, размещенных на перезагружаемом узле. После остановки процесса индексирования можно выполнить следующие действия:
1. Отключить распределение шардов, чтобы предотвратить их перераспределение на другие узлы во время перезапуска узла, с помощью следующей команды:
| 1 2 3 4 5 6 | PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "primaries" } } |
Следует отметить, что по умолчанию процесс перемещения шардов запускается только через одну минуту, и эту задержку можно настроить с помощью параметра индекса `index.unassigned.node_left.delayed_timeout`.
2. После того как перемещение шардов отключено, необходимо промыть журналы транзакций (с помощью команды, приведенной ниже), что обеспечит безопасную фиксацию всех операций, хранящихся в журнале транзакций, в индексе Lucene на диске. Это позволит сэкономить время при перезапуске, поскольку не придется воспроизводить операции, а значит, восстановление шардов будет происходить быстрее.
| 1 | POST /_flush |
Обратите внимание, что до версии ES 8.0 эта операция называлась synced-flush, но в версии 7.6 она была устаревшей, а в версии 8.0 была удалена.
3. На этом этапе можно перезапустить узел.
4. После перезапуска узла можно снова включить выделение шардов с помощью следующей команды:
| 1 2 3 4 5 6 | PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": null } } |
Если необходимо перезагрузить несколько узлов или выполнить полный перезапуск кластера, можно использовать ту же процедуру. Для ускорения процесса восстановления следует помнить о необходимости прекращения индексирования и промывки журнала транзакций.
Пока идет процесс восстановления, существует несколько вызовов API, позволяющих отслеживать состояние восстановления шардов:
| 1 2 3 | # Проверка состояния восстановления конкретного индекса GET /<index>/_recovery |
| 1 2 | # Проверка состояния восстановления всех индексов GET /_recovery |
| 1 2 | # Проверка состояния восстановления всех индексов (более лаконичный формат) GET _cat/recovery |
Настройка скорости восстановления
Если по каким-либо причинам вы не можете остановить процесс индексирования, можно выполнить ту же процедуру. Однако, поскольку во время перезапуска узла будут поступать новые данные, все операции индексирования придется воспроизводить заново, что замедлит процесс восстановления. Однако есть несколько регуляторов, которые можно настроить для ускорения этого процесса при условии наличия достаточных аппаратных ресурсов (процессор, оперативная память, сеть).
По умолчанию общий входящий и исходящий трафик восстановления на каждом горячем и теплом узле данных ограничен скоростью 40 Мбит/с. Для выделенных холодных и замороженных узлов это ограничение составляет от 40 до 250 Мбит/с в зависимости от общего объема памяти, доступной на этих узлах. Эти значения по умолчанию были определены эмпирически, исходя из предположения, что оборудование состоит из стандартных SSD-дисков и сетевого интерфейса с пропускной способностью 1 Гбит/с. Если у вас более мощное оборудование (например, сеть 10 Гбит/с и диски 100K IOPS), вы можете увеличить лимит трафика восстановления до более высокого значения с помощью следующей команды:
| 1 2 3 4 5 6 | PUT /_cluster/settings { "transient": { "indices.recovery.max_bytes_per_sec": "100mb" } } |
При изменении этого параметра следует быть очень осторожным, так как слишком большое значение может повредить производительности кластера. Кроме того, существует еще несколько экспертных настроек, которые можно изменить, если требуется оптимизировать процесс восстановления, но изменять значения по умолчанию в этих экспертных настройках настоятельно не рекомендуется, если вы не знаете, что именно вы делаете.
Заключение
В этом руководстве мы рассказали о том, что представляет собой процесс восстановления шардов и при каких обстоятельствах он запускается. Мы также рассмотрели несколько методов ускорения процесса восстановления и рассказали о том, на что следует обратить внимание, когда вы начинаете изменять значения параметров восстановления по умолчанию.