Учебники

Миграция между версиями

Октябрь 3, 2018

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

Ниже приведены шаги по обновлению Elasticsearch —

  • Прочитайте документацию по изменениям с https://www.elastic.co/
  • Протестируйте обновленную версию в непроизводственной среде, например в среде UAT, E2E, SIT или DEV.
  • Откат к предыдущей версии Elasticsearch невозможен без резервного копирования данных. Перед обновлением до более поздней версии рекомендуется сделать резервную копию данных.
  • Мы можем выполнить обновление с помощью полного перезапуска кластера или непрерывного обновления. Прокатное обновление для новых версий (для 2.x и новее). Нет никакого перебоя в обслуживании, когда вы используете скользящий метод обновления для миграции.
Старая версия Новая версия Метод обновления
0.90.x 2.x Полный перезапуск кластера
1.x 2.x Полный перезапуск кластера
2.x 2.y Скользящее обновление (y> x)
  • Сделайте резервную копию данных перед миграцией и следуйте инструкциям, чтобы выполнить процесс резервного копирования. Модуль моментальных снимков и восстановления можно использовать для резервного копирования. Этот модуль может использоваться для создания снимка индекса или полного кластера и может храниться в удаленном хранилище.

Модуль моментальных снимков и восстановления

Перед началом процесса резервного копирования хранилище моментальных снимков необходимо зарегистрировать в Elasticsearch. 

PUT /_snapshot/backup1
{
   "type": "fs", "settings": {
      ... repository settings ...
   }
}

Примечание. Приведенный выше текст представляет собой HTTP-запрос PUT на http: // localhost: 9200 / _snapshot / backup1 (вместо localhost может быть IP-адрес удаленного сервера). Остальная часть текста является телом запроса. Вы можете сделать это легко, используя fiddler2 и другие веб-инструменты в Windows.

Мы используем общую файловую систему (тип: fs) для резервного копирования; это должно быть зарегистрировано в каждом главном узле и узлах данных. Нам просто нужно добавить переменную path.repo, имеющую путь к хранилищу резервных копий в качестве значения.

После того, как мы добавим путь к хранилищу, нам нужно перезапустить узлы, и тогда можно будет выполнить регистрацию, выполнив следующую команду: 

PUT http://localhost:9200/_snapshot/backup1
{
   "type": "fs", "settings": {
      "location": "/mount/backups/backup1", "compress": true
   }
}

Полный перезапуск кластера

Этот процесс обновления включает в себя следующие шаги —

Шаг 1 — Отключить процесс выделения осколков и выключить узел. 

PUT http://localhost:9200/_cluster/settings
{
   "persistent": {
      "cluster.routing.allocation.enable": "none"
   }
}

В случае обновления 0.90.x до 1.x используйте следующий запрос — 

PUT http://localhost:9200/_cluster/settings
{
   "persistent": {
      "cluster.routing.allocation.disable_allocation": false,
      "cluster.routing.allocation.enable": "none"
   }
}

Шаг 2 — Сделайте синхронизированный сброс в Elasticsearch — 

POST http://localhost:9200/_flush/synced

Шаг 3 — На всех узлах убейте все эластичные сервисы.

Шаг 4 — Сделайте следующее на каждом узле —

  • В Debian или Red Hat Node — rmp или dpkg могут использоваться для обновления узла путем установки новых пакетов. Не перезаписывайте конфигурационные файлы.

  • В Windows (zip-файл) или UNIX (tar-файл) — Извлеките новую версию, не перезаписывая каталог конфигурации. Вы можете скопировать файлы из старой установки или изменить path.conf или path.data.

В Debian или Red Hat Node — rmp или dpkg могут использоваться для обновления узла путем установки новых пакетов. Не перезаписывайте конфигурационные файлы.

В Windows (zip-файл) или UNIX (tar-файл) — Извлеките новую версию, не перезаписывая каталог конфигурации. Вы можете скопировать файлы из старой установки или изменить path.conf или path.data.

Шаг 5 — Инициируйте узлы снова, начиная с главного узла (узлы с установленным значением true для узла node.master и установленным значением false для параметра node.data) в кластере. Подождите некоторое время, чтобы установить кластер. Вы можете проверить, отслеживая журналы или используя следующий запрос — 

GET _cat/health or http://localhost:9200/_cat/health
GET _cat/nodes or http://localhost:9200/_cat/health

Шаг 6 — Отслеживайте ход формирования кластера с помощью запроса GET _cat / health и ждите желтого в ответе, ответ будет примерно таким: 

1451295971 17:46:11 elasticsearch yellow 1 1 5 5 0 0 5 0 - 50.0%

Шаг 7. Включите процесс выделения сегмента, который был отключен на шаге 1, с помощью следующего запроса: 

PUT http://localhost:9200/_cluster/settings
{
   "persistent": {
      "cluster.routing.allocation.enable": "all"
   }
}

В случае обновления 0.90.x до 1.x используйте следующий запрос — 

PUT http://localhost:9200/_cluster/settings
{
   "persistent": {
      "cluster.routing.allocation.disable_allocation": true,
      "cluster.routing.allocation.enable": "all"
   }
}

Роллинг Обновления

Это похоже на полный перезапуск кластера, кроме шага 3. Здесь вы останавливаете один узел и выполняете обновление. После обновления перезапустите узел и повторите их для всех узлов. После включения процесса выделения сегмента его можно отслеживать с помощью следующего запроса:

45
Share: