Отказоустойчивость Elasticsearch: реплики + snapshot + CCR

Симптом

Цель: обеспечить отказоустойчивость Elasticsearch с помощью реплик шардов, выделенных master/data-узлов, резервных копий через снапшоты (SLM) и межкластерной репликации (CCR).

1. Разделение ролей: выделенные master- и data-узлы

Для стабильности кластера голосующие master-eligible узлы (желательно 3, нечётное большинство) отделяются от рабочей нагрузки данных. Назначайте роли через node.roles в elasticsearch.yml и задайте seed hosts для обнаружения. 3 master-узла предотвращают split-brain.

Elasticsearch

# elasticsearch.yml on master nodes:
# node.roles: [ master ]
# on data nodes:
# node.roles: [ data, ingest ]
# discovery.seed_hosts: [ m1, m2, m3 ]
# cluster.initial_master_nodes: [ m1, m2, m3 ]

2. Задайте число реплик индекса

number_of_replicas — число копий каждого primary-шарда; оно должно быть не меньше 1, чтобы данные оставались доступными при потере data-узла. Его можно менять динамически на работающем индексе; число реплик должно быть меньше числа data-узлов.

Elasticsearch

PUT /orders/_settings
{
  "index": { "number_of_replicas": 1 }
}
# default via template (composable template; the old _template API is legacy):
# PUT _index_template/order-tpl { "index_patterns": ["order*"], "template": { "settings": { "number_of_replicas": 1 } } }

3. Определите репозиторий снапшотов

Резервные копии сохраняются в репозиторий: общую файловую систему (fs) или через плагины S3/GCS/Azure. Чтобы восстановить данные даже после удаления кластера, репозиторий должен находиться на надёжном хранилище вне кластера.

Elasticsearch

PUT /_snapshot/backup_repo
{
  "type": "fs",
  "settings": { "location": "/mnt/es_backups", "compress": true }
}

4. Настройте автоматические снапшоты с SLM

Snapshot Lifecycle Management (SLM) делает регулярные снапшоты и применяет политику хранения. Выражение cron задаёт периодичность, включаемые индексы и число хранимых снапшотов.

Elasticsearch

PUT /_slm/policy/daily_backup
{
  "schedule": "0 30 1 * * ?",
  "name": "<daily-{now/d}>",
  "repository": "backup_repo",
  "config": { "indices": ["*"] },
  "retention": { "expire_after": "30d", "min_count": 5, "max_count": 50 }
}

5. Проверьте снапшот и восстановление

Запустите политику SLM вручную, чтобы убедиться в её работе; состояние снапшота должно быть SUCCESS. Регулярно проводите тесты восстановления: непроверенный бэкап — не бэкап.

Elasticsearch

POST /_slm/policy/daily_backup/_execute
GET /_snapshot/backup_repo/_all
# restore:
POST /_snapshot/backup_repo/<snapshot_name>/_restore

6. Настройте удалённый DR с Cross-Cluster Replication (CCR)

Для аварийного восстановления между регионами второй кластер (follower) следует за индексами удалённого основного кластера (leader). Сначала определите удалённый кластер, затем привяжите follower-индекс к leader; изменения на leader поступают автоматически. CCR — функция уровня Platinum (коммерческая).

Elasticsearch

# define the remote cluster on the follower cluster:
PUT /_cluster/settings
{ "persistent": { "cluster": { "remote": { "primary": { "seeds": ["leader1:9300"] } } } } }
# create the follower index:
PUT /orders-follower/_ccr/follow
{ "remote_cluster": "primary", "leader_index": "orders" }