Resiliência do Elasticsearch: réplica + snapshot + CCR

Sintoma

Objetivo: dar resiliência ao Elasticsearch com shards de réplica, nós master/data dedicados, backups por snapshot (SLM) e cross-cluster replication (CCR).

1. Separe os papéis: nós master e data dedicados

Para a estabilidade do cluster, os nós master-eligible votantes (de preferência 3, uma maioria ímpar) são separados da carga de dados. Atribua os papéis com node.roles no elasticsearch.yml e defina os seed hosts para o discovery. 3 masters evitam 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. Defina o número de réplicas do índice

number_of_replicas é o número de cópias mantidas para cada shard primário; deve ser pelo menos 1 para que os dados continuem disponíveis quando um data node for perdido. Pode ser alterado dinamicamente em um índice ativo; o número de réplicas deve ser menor que o número de data nodes.

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. Defina um repositório de snapshots

Os backups são feitos em um repositório: um sistema de arquivos compartilhado (fs) ou os plugins S3/GCS/Azure. Para poder recuperar os dados mesmo se o cluster for apagado, o repositório precisa estar em armazenamento durável fora do cluster.

Elasticsearch

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

4. Agende snapshots automáticos com SLM

O Snapshot Lifecycle Management (SLM) tira snapshots regulares e aplica uma política de retenção. Uma expressão cron define a frequência, quais índices entram e quantos snapshots são mantidos.

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. Verifique o snapshot e o restore

Dispare a política SLM manualmente para verificar se funciona; o estado do snapshot deve ser SUCCESS. Faça testes de restore regularmente, porque backup não testado não é backup.

Elasticsearch

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

6. Configure DR remoto com Cross-Cluster Replication (CCR)

Para recuperação de desastres entre regiões, um segundo cluster (follower) segue os índices do cluster primário remoto (leader). Primeiro defina o remote cluster e depois vincule o índice follower ao leader; as alterações no leader fluem automaticamente. CCR é um recurso Platinum (comercial).

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" }