› ›

Поэтапное обновление

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

При выполнении поэтапного обновления:

Обновите узлы, которые не являются узлами-мастерами. Вы можете получить список этих узлов с помощью GET /_nodes/_all,master:false или найдя все узлы, настроенные с помощью node.master: false.
Обновляйте узлы по уровням, начиная с уровня frozen. Завершите обновление всех узлов на каждом уровне данных перед переходом к следующему. Обновите уровень frozen, затем cold, затем warm и, наконец, hot. Это гарантирует, что ILM может продолжать перемещать данные по уровням во время обновления. Вы можете получить список узлов на определенном уровне с помощью запроса GET /_nodes, например: GET /_nodes/data_frozen:true/_none.
В последнюю очередь обновите узлы, имеющие право быть мастерами. Вы можете получить список этих узлов с помощью GET /_nodes/master:true.

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

Поэтапные обновления поддерживаются:

Между младшими версиями одной и той же основной версии
С версии 5.6 до 6.8
С версии 6.8 до 7.17.28
С любой версии с 7.17.0 до 7.17.28

Обновление непосредственно до 7.17.28 с версии 6.7 или более ранней требует полного перезапуска кластера.

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

Важно тщательно подготовиться перед началом обновления. После начала обновления кластера до версии 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"
  }
}
```
Остановить некритичные операции индексирования и выполнить синхронизированное сброс. (Необязательно)

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

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

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

Если ваши индексы машинного обучения были созданы в версии 6.x, вы можете:
- Оставить ваши задания машинного обучения в работе во время обновления. При остановке узла машинного обучения его задачи автоматически перемещаются на другой узел и восстанавливают состояния моделей. Этот вариант позволяет вашим заданиям продолжить работу во время обновления, но увеличивает нагрузку на кластер.
- Временно приостановить задачи, связанные с вашими заданиями машинного обучения и каналами данных, и предотвратить открытие новых заданий, используя 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)
```
Обновить узел, который вы остановили.

Для обновления с помощью пакета 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.

При выполнении плавного обновления вы должны оставить cluster.initial_master_nodes без значения. Каждый обновленный узел присоединяется к существующему кластеру, поэтому нет необходимости в инициализации кластера. Вы должны настроить либо discovery.seed_hosts, либо discovery.seed_providers на каждом узле.
Обновить все плагины.

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

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

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

Перед обновлением следующего узла дождитесь завершения распределения фрагментов в кластере. Вы можете проверить процесс, отправив запрос _cat/health:
```
GET _cat/health?v=true
```
Дождитесь, пока столбец status переключится на значение green. Как только узел будет green, все первичные и реплицированные фрагменты будут распределены.

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

Если невозможно назначить реплики фрагментов другому узлу (в кластере только один обновленный узел), реплики фрагментов останутся неназначенными, а статус останется yellow.

В этом случае вы можете продолжить, когда не будет инициализирующих или перемещающихся фрагментов (проверьте столбцы init и relo).

Как только будет обновлен другой узел, реплики фрагментов смогут быть назначены, и статус изменится на green.

Фрагменты, которые не были синхронизированы, могут дольше восстанавливаться. Вы можете отслеживать статус восстановления отдельных фрагментов, отправив запрос _cat/recovery:
```
GET _cat/recovery
```
Если вы остановили индексирование, вы можете безопасно возобновить индексирование, как только завершится восстановление.
Повторить

Когда узел восстановится и кластер будет стабилен, повторите эти шаги для каждого узла, который требуется обновить. Вы можете отслеживать состояние кластера с помощью запроса _cat/health:
```
GET /_cat/health?v=true
```
И проверить, какие узлы были обновлены с помощью запроса _cat/nodes:
```
GET /_cat/nodes?h=ip,name,version&v=true
```

Перезапустить задачи машинного обучения.

Если вы временно приостановили задачи, связанные с вашими задачами машинного обучения, используйте API установки режима обновления, чтобы вернуть их в активное состояние:
```
POST _ml/set_upgrade_mode?enabled=false
```
Если вы закрыли все задачи машинного обучения до обновления, откройте задачи и запустите каналы данных из Kibana или с помощью 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/rolling-upgrades.html