Problemas de Alocação de Shards no Elasticsearch: Causas e Soluções

Os problemas de alocação de shards no Elasticsearch geralmente aparecem como saúde do cluster amarela ou vermelha. Amarelo significa que seus shards primários estão atribuídos, mas pelo menos uma réplica não está. Vermelho significa que pelo menos um shard primário não está atribuído, então alguns dados podem estar indisponíveis até que você os recupere.

Este guia mostra como encontrar o bloqueador de alocação, ler a saída da API Allocation Explain e escolher a correção menos arriscada. O objetivo é restaurar a alocação sem piorar a perda de dados.

Entendendo os Estados dos Shards e a Saúde do Cluster

Shards são a unidade que o Elasticsearch coloca entre os nós de dados. Eles podem existir em vários estados:

• STARTED: O shard está ativo e atendendo requisições.
• RELOCATING: O shard está se movendo de um nó para outro.
• INITIALIZING: O shard está sendo criado ou recuperado.
• UNASSIGNED: O shard existe nos metadados do cluster, mas não está alocado a um nó.

A saúde do cluster segue esses estados de shard:

• Green: Todos os shards primários e réplicas estão alocados.
• Yellow: Todos os shards primários estão alocados, mas uma ou mais réplicas não estão atribuídas.
• Red: Um ou mais shards primários não estão atribuídos. As pesquisas podem retornar resultados parciais ou falhar para índices afetados, e as gravações nesses índices podem falhar.

Causas Comuns de Falhas na Alocação de Shards

O Elasticsearch usa decisors de alocação antes de colocar um shard. Uma única decisão NO pode manter um shard não atribuído.

Marcas d'Água de Disco

A pressão do disco é uma das causas mais comuns. O Elasticsearch usa marcas d'água de disco para evitar encher um nó. Quando um nó ultrapassa a marca baixa ou alta, as decisões de alocação se tornam mais restritivas. No estágio de inundação, o Elasticsearch pode adicionar um bloco somente leitura aos índices afetados para proteger o nó de ficar sem disco.

Configuração	Padrão Comum	Efeito
cluster.routing.allocation.disk.watermark.low	85%	Evita alocar shards adicionais a nós acima deste limite.
cluster.routing.allocation.disk.watermark.high	90%	Tenta mover shards para longe e evita colocar shards no nó.
cluster.routing.allocation.disk.watermark.flood_stage	95%	Pode bloquear gravações em índices afetados.

Confirme as configurações reais do seu cluster antes de alterar qualquer coisa:

GET /_cluster/settings?include_defaults=true&filter_path=**.disk.watermark*

Em seguida, verifique o uso do disco do nó:

GET /_cat/allocation?v&h=node,disk.used_percent,disk.avail,disk.total,shards

Libere espaço, adicione disco, adicione nós de dados, exclua índices antigos ou reduza a pressão da réplica. Se um bloco de estágio de inundação foi definido, remova-o somente após a pressão do disco ser corrigida:

PUT /my_index/_settings
{
  "index.blocks.read_only_allow_delete": null
}

Funções de Nó e Filtros de Alocação

Os shards de índice são alocados apenas para nós com função de dados e filtros de alocação correspondentes. Se você usar atributos de nó para camadas hot/warm, racks, zonas ou tipos de armazenamento, um erro de digitação pode deixar shards órfãos.

Por exemplo, um índice com index.routing.allocation.require.box_type: high_io será alocado apenas em nós configurados com node.attr.box_type: high_io.

Verifique os filtros de índice e atributos do nó:

GET /my_index/_settings?filter_path=*.settings.index.routing.allocation
GET /_cat/nodeattrs?v
GET /_cat/nodes?v&h=name,roles,disk.used_percent

Corrija a configuração do índice ou adicione um nó de dados elegível. Não remova a conscientização de alocação casualmente em clusters multizona; isso pode colocar todas as cópias de um shard no mesmo domínio de falha.

Shards Primários Ausentes

Se um shard primário não está atribuído, o nó que mantinha o primário ativo pode ter desaparecido, o índice pode ter acabado de ser restaurado ou as regras de alocação podem estar bloqueando todos os nós elegíveis. Não presuma que os dados estão perdidos até que a API Allocation Explain lhe diga por que o Elasticsearch não pode alocar o shard.

Cenários comuns incluem:

• Um nó que continha a única cópia primária boa falhou.
• Os filtros de alocação excluem todos os nós de dados que poderiam hospedar o primário.
• Uma restauração de snapshot ou criação de índice está aguardando nós elegíveis.
• Existe uma cópia de shard desatualizada, mas o Elasticsearch não a promoverá sem aceitação explícita de perda de dados.

Primeiro, tente recuperar o nó ausente, restaurar um snapshot ou corrigir o bloqueador de alocação. Use a alocação primária forçada somente quando você entender qual cópia está desatualizada ou quando tiver aceitado a perda de dados para esse shard.

Limites de Shards

Os limites de shards por nó também podem bloquear a alocação. Configurações comuns incluem index.routing.allocation.total_shards_per_node e cluster.routing.allocation.total_shards_per_node.

Verifique esses limites:

GET /_cluster/settings?include_defaults=true&filter_path=**.total_shards_per_node
GET /my_index/_settings?filter_path=*.settings.index.routing.allocation.total_shards_per_node

Adicione nós, reduza a contagem de réplicas, consolide índices pequenos ou aumente cautelosamente o limite relevante. Muitos shards por nó podem aumentar a pressão no heap e desacelerar as operações de estado do cluster.

Diagnosticando com a API Allocation Explain

A API Allocation Explain é a melhor ferramenta para responder "por que este shard não está alocando?"

GET /_cluster/allocation/explain?pretty
{
  "index": "my_data",
  "shard": 0,
  "primary": true
}

Para deixar o Elasticsearch escolher um shard atualmente não atribuído, chame a API sem corpo:

GET /_cluster/allocation/explain?pretty

Leia estes campos primeiro:

• can_allocate: A resposta de alto nível.
• allocate_explanation: O resumo em linguagem simples.
• node_allocation_decisions: Decisões por nó.
• deciders: A regra exata que retornou NO ou THROTTLE.

Uma decisão NO é o bloqueador. Uma decisão THROTTLE geralmente significa que o Elasticsearch pode alocar o shard, mas está limitando o trabalho de recuperação concorrente.

Sequência Segura de Solução de Problemas

Comece amplo, depois reduza.

1. Verifique a Saúde do Cluster e Shards Não Atribuídos

GET /_cluster/health?pretty
GET /_cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node

Observe unassigned.reason. Valores como NODE_LEFT, INDEX_CREATED, CLUSTER_RECOVERED ou ALLOCATION_FAILED indicam onde procurar em seguida.

2. Verifique o Disco e a Elegibilidade do Nó

GET /_cat/allocation?v&h=node,disk.used_percent,disk.avail,disk.total
GET /_cat/nodes?v&h=name,roles,heap.percent,ram.percent,cpu,disk.used_percent

Se os nós estiverem próximos da marca d'água alta, corrija a pressão do disco antes de alterar as configurações de alocação.

3. Execute Allocation Explain

Use o índice afetado, o número do shard e o sinalizador primário/réplica. A saída deve nomear a configuração, condição do nó ou decisor que bloqueia a alocação.

4. Evite Roteamentos Arriscados Até Saber a Causa

Comandos de reroteamento manual são para casos específicos de recuperação. Eles não são uma correção geral para pressão de disco, filtros ruins ou muitas réplicas.

Se uma cópia primária desatualizada for o único caminho prático de recuperação, o comando se parece com isso:

POST /_cluster/reroute
{
  "commands": [
    {
      "allocate_stale_primary": {
        "index": "index_name",
        "shard": 0,
        "node": "node_name_with_stale_copy",
        "accept_data_loss": true
      }
    }
  ]
}

accept_data_loss: true é necessário por um motivo. Use-o somente depois de verificar snapshots, tentar recuperar o nó ausente e confirmar qual nó contém a cópia desatualizada.

5. Trate a Saúde Amarela Separadamente

Se apenas as réplicas não estiverem atribuídas, o cluster ainda pode servir dados primários. Corrija a restrição de recurso subjacente primeiro. Adicionar um nó de dados, limpar o disco ou corrigir filtros de alocação geralmente permite que o Elasticsearch atribua réplicas automaticamente.

Se você precisar executar temporariamente sem réplicas, reduza a contagem de réplicas para o índice afetado:

PUT /my_index/_settings
{
  "index.number_of_replicas": 0
}

Isso pode fazer a saúde ficar verde porque o Elasticsearch não espera mais cópias de réplica para esse índice. Também reduz a disponibilidade, então defina as réplicas de volta ao valor desejado após adicionar capacidade ou corrigir a alocação.

Prevenindo Problemas de Alocação

• Alerte antes que os nós cruzem a marca d'água alta do disco.
• Mantenha nós de dados suficientes disponíveis para sua contagem de réplicas e regras de conscientização de alocação.
• Use contagens de shards que se ajustem ao seu heap, volume de dados e metas de recuperação.
• Revise os modelos de índice para que novos índices não herdem contagens de réplicas ou filtros de alocação ruins.
• Teste a substituição de nós e as etapas de restauração de snapshot antes de um incidente.

Conclusão

Seu caminho mais seguro é simples: identifique o shard não atribuído, execute Allocation Explain, corrija o decisor que diz NO e evite alocação forçada a menos que você tenha aceitado a troca de perda de dados.