Опис
Все почалося з міграції кластеру еластіки зі стійки в 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 – коли вказаний false, Elastic не додає стан глобального кластера в знімок, це дозволяє без проблем відновити знімок на іншому кластері з різними атрибутами.
Для того щоб перевірити й ознайомитись які доступні нам знімки, використовуємо наступну команду:
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 – коли вказаний false, Elastic не додає стан глобального кластера в знімок, це дозволяє без проблем відновити знімок на іншому кластері з різними атрибутами.
- _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, тепер офіційно відновлення снапшоту завершено)
Посилання по темі
- https://qbox.io/blog/elasticsearch-data-snapshots-restore-tutorial
- https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshots-register-repository.html
- https://www.elastic.co/guide/en/elasticsearch/plugins/current/listing-removing-updating.html
- https://www.elastic.co/guide/en/elasticsearch/reference/7.17/snapshots-take-snapshot.html