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

Опис

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

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

Підготовка

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

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

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

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

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

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

# директорія репозиторію в якій зберігатимуться наші знімки:
mkdir /tmp/elasticsearch-backup

# відповідні права для доступу до директорії:
chown -R elasticsearch:elasticsearch /tmp/elasticsearch-backup

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

echo 'path.repo: ["/tmp/elasticsearch-backup"]' >> /etc/elasticsearch/elasticsearch.yml

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

systemctl restart elasticsearch

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

curl -XPUT 'http://localhost:9200/_snapshot/backup_repo' -H 'Content-Type: application/json' -d '
{
  "type": "fs",
  "settings": {
    "location": "/tmp/elasticsearch-backup",
    "compress": true
  }
}'дь

де:

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

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

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

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

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

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install repository-s3

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

echo '-Des.allow_insecure_settings=true' >> /etc/elasticsearch/jvm.options

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

systemctl restart elasticsearch

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

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin list

# Output
repository-s3

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

curl http://localhost:9200/_nodes?filter_path=nodes.*.plugins | jq

# OUTPUT
{  
 "nodes": {
    "EnM2PZMzQH*******": {
      "plugins": [
        {
          "name": "repository-s3",
          "version": "6.8.13",
          "elasticsearch_version": "6.8.13",
          "java_version": "1.8",
          "description": "The S3 repository plugin adds S3 repositories",
          "classname": "org.elasticsearch.repositories.s3.S3RepositoryPlugin",
          "extended_plugins": [],
          "has_native_controller": false
        }
      ]
    },
    "mYnPM5E-S*******Q": {
      "plugins": [
        {
          "name": "repository-s3",
          "version": "6.8.13",
          "elasticsearch_version": "6.8.13",
          "java_version": "1.8",
          "description": "The S3 repository plugin adds S3 repositories",
          "classname": "org.elasticsearch.repositories.s3.S3RepositoryPlugin",
          "extended_plugins": [],
          "has_native_controller": false
        }
      ]
    }
  }
}

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

curl -X PUT "localhost:9200/_snapshot/backup_repo?pretty" -H 'Content-Type: application/json' -d' 
{ 
  "type": "s3", 
  "settings": { 
     "bucket": "elasticsearch-repo",
     "region": "0",
     "access_key": "AKI**********OF",
     "secret_key": "****R/Ip****/YXs*****3m*****mi**" 
   } 
}'

де:

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

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

curl -XGET http://localhost:9200/_cat/repositories?pretty

# OUTPUT
backup_repo   s3

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

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

curl -XPUT "http://localhost:9200/_snapshot/backup_repo/es_backup_28_12_2022"

# OUTPUT
{"accepted":true}

де:

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

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

curl -X PUT "localhost:9200/_snapshot/backup_repo/es_backup_28_12_2022?wait_for_completion=true&pretty" -H 'Content-Type:application/json' -d'
{
  "indices": "index_1,index_2",
  "ignore_unavailable": true,
  "include_global_state": false
 }
'

де:

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

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

curl http://localhost:9200/_cat/snapshots/backup_repo?v

# OUTPUT
id status start_epoch start_time end_epoch end_time duration indices successful_shards failed_shards total_shards
es_backup_28_12_2022 SUCCESS 1672231714 12:48:34 1672232773 13:06:13 17.6m 343 659 0 659

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

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

curl -XPOST http://localhost:9200/_snapshot/backup_repo/es_backup_28_12_2022/_restore

де:

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

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

curl -X PUT "localhost:9200/_snapshot/backup_repo/es_backup_28_12_2022/_restore" -H 'Content-Type:application/json' -d'
{
  "indices": "index_1,index_2",
  "ignore_unavailable": true,
  "include_global_state": false
}'

де:

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

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

curl 'localhost:9200/_cat/indices?v'

# OUTPUT
health status index               uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   *-log-**-2022.01.02 ldi0MuJqTdqW3X5eKN1IRw 2   1   9592       0            17.1mb     8.5mb
green  open   *-log-**-2022.05.17 wX1um8xOSvKIB-Q65NpPlQ 2   1   54038      0            157.4mb    78.7mb
green  open   *-log-**-2022.06.05 kgKR6l7IQZuTvizyLzb_lg 2   1   24156      0            43.2mb     21.6mb
green  open   *-log-**-2022.05.31 N0YpKHliR_i5nHe9Z7GnZw 2   1   58084      0            161.2mb    80.6mb
green  open   *-log-**-2022.08.06 eYdPJAmPQ4moYADQW_skWw 2   1   218552     0            271.2mb    135.6mb
green  open   .kibana_1           -qiooA0aSP64PCxdCt97jg 1   1   64         1            331.2kb    165.6kb
green  open   **-2022.12.28       XsQnJSv8RuiCDz8ln0X7AQ 2   1   33650      0            77mb       38.5mb

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

curl -XGET 'localhost:9200/_cluster/health?pretty'
{
  "cluster_name" : "elasticsearch",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 2,
  "number_of_data_nodes" : 2,
  "active_primary_shards" : 447,
  "active_shards" : 447,
  "relocating_shards" : 0,
  "initializing_shards" : 8,
  "unassigned_shards" : 863,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 33.91502276176024
}

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

curl -XGET 'localhost:9200/_cluster/health?pretty'
{
  "cluster_name" : "elasticsearch",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 2,
  "number_of_data_nodes" : 2,
  "active_primary_shards" : 659,
  "active_shards" : 1318,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

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

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

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