› ›

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

Для обновления до Elasticsearch 7.17.28 с версий 6.0-6.7 необходимо остановить все узлы кластера, обновить каждый узел до 7.17.28 и перезапустить кластер.

Если вы используете версию до 6.0, обновитесь до 6.8 и переиндексируйте старые индексы или создайте новый кластер версии 7.17.28 и переиндексируйте из удалённого.

Подготовка к обновлению

Важно тщательно подготовиться перед началом обновления. После начала обновления кластера до версии 7.17.28, необходимо завершить обновление. Как только кластер будет содержать узлы версии 7.17.28, он может внести изменения в своё внутреннее состояние, которые невозможно будет отменить. Если обновление невозможно завершить, необходимо отбросить частично обновлённый кластер, развернуть пустой кластер предыдущей версии и восстановить его содержимое из снимка.

Перед началом обновления кластера до версии 7.17.28 необходимо выполнить следующие действия:

Проверьте журнал устаревших функций, чтобы узнать, используете ли вы устаревшие функции, и соответствующим образом обновите свой код.
Просмотрите изменения, требующие переработки, и внесите необходимые изменения в свой код и конфигурацию для версии 7.17.28.
Если вы используете плагины, убедитесь, что есть версия каждого плагина, совместимая с Elasticsearch версии 7.17.28.
Протестируйте обновление в изолированной среде перед обновлением вашего производственного кластера.
Создайте резервную копию данных, сделав снимок!

Обновление кластера

Для выполнения полного обновления кластера с перезапуском до версии 7.17.28:

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

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

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

Обратите внимание, что синхронизированная операция flush устарела и будет удалена в версии 8.0. Операция flush имеет такой же эффект, как синхронизированная операция flush в Elasticsearch 7.6 или более поздних версиях.
Временно остановить задачи, связанные с активными заданиями машинного обучения и datafeed. (Необязательно)

Если индексы машинного обучения были созданы до версии 6.x, необходимо переиндексировать индексы.

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

Если вы обновляетесь с кластера 6.2 или более ранней версии и используете X-Pack, запустите bin/elasticsearch-plugin remove x-pack для удаления плагина X-Pack перед обновлением. Функциональность X-Pack теперь включена в базовое распределение и больше не устанавливается отдельно. Узел не запустится после обновления, если плагин X-Pack присутствует. Вам нужно будет выполнить понижение версии, удалить плагин и повторно применить обновление.

Для обновления с помощью пакета Debian или RPM:
- Используйте rpm или dpkg для установки нового пакета. Все файлы устанавливаются в соответствующее местоположение для операционной системы, и конфигурационные файлы Elasticsearch не перезаписываются.
Для обновления с помощью архива zip или tar:
1. Извлеките zip или tar-архив в новую директорию. Это критически важно, если вы не используете внешние каталоги config и data.
2. Установите переменную окружения ES_PATH_CONF, чтобы указать расположение внешнего каталога config и файла jvm.options. Если вы не используете внешний каталог config, скопируйте старую конфигурацию в новую установку.
3. Установите path.data в config/elasticsearch.yml, чтобы указать расположение внешнего каталога данных. Если вы не используете внешний каталог data, скопируйте ваш старый каталог данных в новую установку.
  
  Если вы используете функции мониторинга, используйте каталог данных при обновлении Elasticsearch. Мониторинг идентифицирует уникальные узлы Elasticsearch, используя постоянный UUID, хранящийся в каталоге данных.
4. Установите path.logs в config/elasticsearch.yml, чтобы указать расположение для хранения журналов. Если вы не укажете это значение, журналы будут храниться в директории, в которую вы извлекли архив.
Когда вы извлекаете zip или tar-пакеты, каталог elasticsearch-n.n.n содержит каталоги Elasticsearch config, data и logs.

Рекомендуется перемещать эти каталоги из директории Elasticsearch, чтобы исключить вероятность их удаления при обновлении Elasticsearch. Для указания новых местоположений используйте переменную окружения ES_PATH_CONF и настройки path.data и path.logs. Более подробную информацию можно найти в Важные настройки Elasticsearch.

Пакеты Debian и RPM размещают эти каталоги в соответствующих местах для каждой операционной системы. В производстве мы рекомендуем установку с помощью пакета deb или rpm.

При обновлении с кластера 6.x, также необходимо настроить инициализацию кластера, установив настройку cluster.initial_master_nodes на узлах, имеющих право быть главными.

Обновите все плагины.

Используйте скрипт elasticsearch-plugin для установки обновлённой версии каждого установленного плагина Elasticsearch. Все плагины должны быть обновлены при обновлении узла.
Если вы используете функции безопасности Elasticsearch для определения областей, убедитесь, что настройки вашей области актуальны. Формат настроек области изменился в версии 7.0, в частности, изменилось расположение типа области. См. Настройки области.
Запустите каждый обновлённый узел.

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

Как только достаточно узлов, имеющих право быть мастерами, обнаружат друг друга, они сформируют кластер и выберут мастера. В этот момент вы можете использовать _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 set upgrade mode для возвращения их в активное состояние:
```
POST _ml/set_upgrade_mode?enabled=false
```
Если вы закрыли все задачи машинного обучения перед обновлением, откройте задачи и запустите данные из Kibana или с помощью API open jobs и start datafeed.

© 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-upgrade.html