› ›

Полная перезагрузка кластера и поэтапная перезагрузка

Возможны случаи, когда требуется выполнить полную перезагрузку всего кластера или поэтапную перезагрузку. В случае полной перезагрузки кластера все узлы кластера останавливаются и перезапускаются, а в случае поэтапной перезагрузки останавливается только по одному узлу за раз, чтобы служба оставалась бесперебойной.

Полная перезагрузка кластера

Отключить распределение фрагментов.

При остановке узла данных процесс распределения ожидает index.unassigned.node_left.delayed_timeout (по умолчанию, одну минуту), прежде чем начать репликацию фрагментов на этом узле на другие узлы кластера, что может потребовать значительных операций ввода-вывода. Поскольку узел вскоре будет перезапущен, эти операции ввода-вывода излишни. Вы можете избежать необходимости ожидания, отключив распределение реплик перед остановкой узлов данных:
```
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}
```
Остановите индексацию и выполните сброс.

Выполнение синхронизированного сброса ускорит восстановление фрагментов.
```
POST _flush/synced
```
После выполнения синхронизированного сброса проверьте ответ, чтобы убедиться, что ошибок нет. Операции синхронизированного сброса, завершившиеся ошибкой из-за ожидающих операций индексации, перечислены в теле ответа, хотя сам запрос всё равно возвращает статус 200 OK. Если возникли ошибки, повторите запрос.

Обратите внимание, что синхронизированный сброс устарел и будет удален в версии 8.0. Сброс имеет тот же эффект, что и синхронизированный сброс в Elasticsearch 7.6 или более поздних версиях.

Временно остановить задачи, связанные с активными заданиями машинного обучения и каналами данных. (Необязательно)

Функции машинного обучения требуют определённой подписки.

У вас есть два варианта обработки задач машинного обучения и каналов данных при остановке кластера:
- Временно приостановить задачи, связанные с задачами машинного обучения и каналами данных, и предотвратить открытие новых задач, используя API установки режима обновления:
```
POST _ml/set_upgrade_mode?enabled=true
```
  При отключении режима обновления задачи возобновляются с последнего сохранённого автоматически состояния модели. Этот вариант позволяет избежать накладных расходов на управление активными задачами во время остановки и выполняется быстрее, чем явное прекращение работы каналов данных и закрытие задач.
- Остановить все каналы данных и закрыть все задачи. Этот вариант сохраняет состояние модели на момент закрытия. При повторном открытии задач после перезапуска кластера они будут использовать точно такое же состояние модели. Однако сохранение последнего состояния модели занимает больше времени, чем использование режима обновления, особенно если у вас много задач или задачи с большими состояниями модели.
Остановите все узлы.
- Если вы используете Elasticsearch с systemd:
```
sudo systemctl stop elasticsearch.service
```
- Если вы используете Elasticsearch с SysV init:
```
sudo -i service elasticsearch stop
```
- Если вы запускаете Elasticsearch как демон:
```
kill $(cat pid)
```
Произведите все необходимые изменения.
Перезапустите узлы.

Если у вас есть выделенные узлы-мастера, запустите их в первую очередь и подождите, пока они не сформируют кластер и не выберут мастера, прежде чем продолжить работу с узлами данных. Вы можете отслеживать процесс, просматривая журналы.

Как только достаточно узлов, имеющих право быть мастерами, обнаружат друг друга, они сформируют кластер и выберут мастера. В этот момент вы можете использовать API cat health и cat nodes для мониторинга присоединения узлов к кластеру:
```
GET _cat/health

GET _cat/nodes
```
Столбец status, возвращаемый _cat/health, отображает состояние каждого узла в кластере: red, yellow или green.
Подождите, пока все узлы присоединятся к кластеру и сообщат о статусе жёлтого.

Когда узел присоединяется к кластеру, он начинает восстанавливать любые первичные фрагменты, которые хранятся локально. API _cat/health изначально сообщает о статусе status red, что указывает на то, что не все первичные фрагменты были распределены.

После того, как узел восстановит свои локальные фрагменты, состояние кластера status переключается на yellow, что указывает на то, что все первичные фрагменты были восстановлены, но не все реплицированные фрагменты распределены. Это ожидаемо, так как вы ещё не включили распределение. Отсрочка распределения реплик до тех пор, пока все узлы будут yellow, позволяет мастеру распределять реплики по узлам, которые уже имеют локальные копии фрагментов.
Включить распределение.

Когда все узлы присоединились к кластеру и восстановили свои первичные фрагменты, включите распределение, вернув cluster.routing.allocation.enable к его значения по умолчанию:
```
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}
```
После включения распределения кластер начинает распределять реплицированные фрагменты по узлам данных. На этом этапе можно безопасно возобновить индексацию и поиск, но ваш кластер восстановится быстрее, если вы можете подождать, пока все первичные и реплицированные фрагменты не будут успешно распределены, и статус всех узлов будет green.

Вы можете отслеживать прогресс с помощью API _cat/health и _cat/recovery:
```
GET _cat/health

GET _cat/recovery
```
Перезапустить задания машинного обучения. (Необязательно)

Если вы временно приостановили задачи, связанные с задачами машинного обучения, используйте API установки режима обновления, чтобы вернуть их в активное состояние:
```
POST _ml/set_upgrade_mode?enabled=false
```
Если вы закрыли все задания машинного обучения перед остановкой узлов, откройте задачи и запустите каналы данных из Kibana или с помощью API открытия задач и запуска каналов данных.

Поэтапная перезагрузка

Отключить распределение фрагментов.

При остановке узла данных процесс распределения ожидает index.unassigned.node_left.delayed_timeout (по умолчанию, одну минуту) перед началом репликации фрагментов на этом узле на другие узлы кластера, что может потребовать значительных операций ввода-вывода. Поскольку узел вскоре будет перезапущен, эти операции ввода-вывода не нужны. Чтобы избежать ненужных операций, можно отключить распределение реплик перед остановкой узлов данных:
```
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}
```
Хотя индексацию можно продолжать во время плавного перезапуска, восстановление фрагментов может пройти быстрее, если временно остановить некритическую индексацию и выполнить сброс.
```
POST /_flush
```
Временно остановить задачи, связанные с активными заданиями машинного обучения и каналами данных. (Необязательно)

Для использования функций машинного обучения требуются соответствующие подписки.

У вас есть два варианта обработки заданий машинного обучения и каналов данных при остановке кластера:
- Временно остановить задачи, связанные с вашими заданиями машинного обучения и каналами данных, и предотвратить открытие новых заданий, используя API установки режима обновления:
```
POST _ml/set_upgrade_mode?enabled=true
```
  При отключении режима обновления задания возобновят работу, используя последнее состояние модели, которое было автоматически сохранено. Этот вариант позволяет избежать накладных расходов на управление активными заданиями во время остановки и быстрее, чем явное прекращение работы каналов данных и закрытие заданий.
- Остановите все каналы данных и закройте все задания. Этот вариант сохраняет состояние модели на момент закрытия. При повторном открытии заданий после перезапуска кластера они будут использовать точно такое же состояние модели. Однако сохранение последнего состояния модели занимает больше времени, чем использование режима обновления, особенно если у вас много заданий или задания с большими состояниями модели.
- Если вы выполняете плавный перезапуск, вы также можете оставить свои задания машинного обучения в работе. При остановке узла машинного обучения его задания автоматически перемещаются на другой узел и восстанавливают состояния модели. Этот вариант позволяет заданиям продолжить работу во время остановки, но увеличивает нагрузку на кластер.
Остановка отдельного узла в случае плавного перезапуска.
- Если вы используете Elasticsearch с systemd:
```
sudo systemctl stop elasticsearch.service
```
- Если вы используете Elasticsearch с SysV init:
```
sudo -i service elasticsearch stop
```
- Если вы используете Elasticsearch в качестве демона:
```
kill $(cat pid)
```
Выполните необходимые изменения.
Перезапустите узел, который вы изменили.

Запустите узел и убедитесь, что он присоединяется к кластеру, проверив файл журнала или отправив запрос _cat/nodes:
```
GET _cat/nodes
```
Включите распределение фрагментов.

Для узлов данных, после того, как узел присоединился к кластеру, удалите настройку cluster.routing.allocation.enable, чтобы включить распределение фрагментов и начать использовать узел:
```
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}
```
Повторите в случае плавного перезапуска.

После восстановления узла и стабилизации кластера повторите эти шаги для каждого узла, который требуется изменить.
Перезапустите задания машинного обучения. (Необязательно)

Если вы временно приостановили задачи, связанные с заданиями машинного обучения, используйте API установки режима обновления, чтобы вернуть их в активное состояние:
```
POST _ml/set_upgrade_mode?enabled=false
```
Если вы закрыли все задания машинного обучения до остановки узлов, откройте задания и запустите каналы данных из Kibana или с помощью API открытия заданий и API запуска каналов данных.

© 2023-2025 Elasticsearch
As of September 2024, Elasticsearch is available under a choice of three licenses: the Server Side Public License (SSPL), the Elastic License, or the AGPLv3 (OSI approved).
Elasticsearch and the Elasticsearch logo are trademarks of Elasticsearch B.V., registered in the U.S. and in other countries.
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/restart-cluster.html