elasticsearch – створення та відновлення снапшоту

Опис

Все почалося з міграції кластеру еластіки зі стійки в AWS, стало ребром питання резервного копіювання та відновлення данних. В даному описі розглянемо як створювати  відновлювати знімки (снапшоти), використовуючи як локальні (fs) так і віддалені сховища (s3 bucker).

Еластік має змогу створювати знімки на нижчій версії  й відновлювати на новішій версії, проте є певні обмеження (з якої версії можна робити і на якій версії можна відномитися), детальніше треба дивитись в документацію тут.  Проте кращим рішенням буде вчасно оновлюватись на актуальні версії еластіки).

Підготовка

Для збереження знімків в Elasticsearch використовуєтьcя так званий репозиторій, в якому зберігаються створені знімки. Репозиторій буває:

  • локальний (виділена директорія на сервері).
  • віддалений (s3bucket / azure / Google Cloud Storage).

При використанні single-node еластіки, можемо користуватись як локальний репозиторієм так і віддаленим.

Коли мова йде про кластерне рішення – локальний репозиторій не підходить. В цьому  випадку використовуємо віддалений, до якого будуть мати доступ всі ноди кластеру, Для тестування обрав в якості віддаленого репозиторію s3 кошик в AWS Для кластерної еластіки всі підготовчі маніпуляції потрібно проводити на кожній ноді (крім створення резервної копії та відновлення)!!!

Локальний репозиторій

На сервері де будемо виконувати резервне копіювання потрібно створити директорію, та надати відповідні права:

після чого, в конфігураційному файлi /etc/elasticsearch/elasticsearch.yml вказуємо створену директорію:

перезапускаємо еластіку:

залишається зареєструвати створений репозиторій:

де:

  • backup_repo – назва репозиторію.
  • type – тип file system.
  • location –  шлях до сховища.
  • compress – вмикаємо стискання для економії місця.

Віддалений репозиторій

Перет тим як встановлювати плагін для роботи з s3 потрібно:

  • створити кошик s3.
  • створити користувача та політику з доступом до даного кошику.
  • ACCESS_KEY та SECRET_KEY користувача для s3.

Встановлюємо плагін:

додаємо параметр в jvm.option:

перезапускаємо еластіку:

можемо подивитися встановлені плагіни:

і на яких нодах він активований:

зареєструємо репозиторій:

де:

  • backup_repo – назва репозиторію.
  • type – вказули що в ролі сховища буде s3 bucket
  • bucket – назва створеного кошику.
  • region – регіон де створено кошик.
  • access_key | secret_key – ключі для доступу в кошик.

Перевіряємо cписок репозиторіїв:

Створення снапшоту

За замовчуванням виконуються знімки всіх індексів, для цього скористаємось наступною командою:

де:

  • backup_repoназва репозиторію.
  • es_backup_28_12_2022назва знімку.

або можемо вказати необхідні індекси:

де:

  • backup_repoназва репозиторію.
  • es_backup_28_12_2022назва знімку.
  • wait_for_completionочікуємо доки виконається знімок, тільки після того повертати статус в вивід.
  • indices – індекси які хочемо забекапити.
  • ignore_unavailable – якщо індекс не створений або видалений він буде пропускатися без завершення команди, якщо виставити false –  тоді команда заверишиться з помилкою.
  • include_global_state – коли вказаний falseElastic не додає стан глобального кластера в знімок, це дозволяє без проблем відновити знімок на іншому кластері з різними атрибутами.

Для того щоб перевірити й ознайомитись які доступні нам знімки, використовуємо наступну команду:

Відновлення з снапшоту

Команда для відновлення:

де:

  • backup_repoназва репозиторію.
  • es_backup_28_12_2022назва створеного знімку.
  • _restore команда для відновлення.

якщо потрібно відновити тільки певний індекс, можемо це вказати:

де:

  • backup_repoназва репозиторію.
  • es_backup_28_12_2022назва знімку.
  • indices – індекси які хочемо відновити.
  • ignore_unavailable – якщо індекс не створений або видалений він буде пропускатися без завершення команди, якщо виставити false –  тоді команда заверишиться з помилкою.
  • include_global_state – коли вказаний falseElastic не додає стан глобального кластера в знімок, це дозволяє без проблем відновити знімок на іншому кластері з різними атрибутами.
  • _restore команда для відновлення.

Після відновлення можемо подивитися список індексів:

та перевірити статус кластеру:

В даному випадку статус Yellow є нормальним, так як не всі шарди ще синхронізувалися (“unassigned_shards” : 863) на інших нодах. Почекаємо трішки й ще раз перевіримо статус:

шарди синхронізувалися (“unassigned_shards” : 0) а статус кластеру став Green, тепер офіційно відновлення снапшоту завершено)

Посилання по темі

Click to rate this post!
[Total: 1 Average: 5]