Tentarei explicar com um exemplo real, pois as respostas e respostas que você recebeu não parecem ajudá-lo.
Quando você baixa o elasticsearch e o inicia, cria um nó elasticsearch que tenta ingressar em um cluster existente, se disponível, ou cria um novo. Digamos que você criou seu próprio novo cluster com um único nó, aquele que você acabou de iniciar. Não temos dados, portanto, precisamos criar um índice.
Quando você cria um índice (um índice é criado automaticamente quando você também indexa o primeiro documento), você pode definir de quantos shards ele será composto. Se você não especificar um número, ele terá o número padrão de shards: 5 primárias. O que isso significa?
Isso significa que a elasticsearch criará 5 shards principais que conterão seus dados:
____ ____ ____ ____ ____
| 1 | | 2 | | 3 | | 4 | | 5 |
|____| |____| |____| |____| |____|
Toda vez que você indexa um documento, a elasticsearch decide qual fragmento primário deve conter esse documento e o indexa lá. Os shards primários não são uma cópia dos dados, são os dados! Ter vários shards ajuda a tirar proveito do processamento paralelo em uma única máquina, mas o ponto principal é que, se iniciarmos outra instância de elasticsearch no mesmo cluster, os shards serão distribuídos de maneira uniforme pelo cluster.
O nó 1 conterá, por exemplo, apenas três fragmentos:
____ ____ ____
| 1 | | 2 | | 3 |
|____| |____| |____|
Desde que os dois shards restantes foram movidos para o nó recém-iniciado:
____ ____
| 4 | | 5 |
|____| |____|
Por que isso acontece? Como o elasticsearch é um mecanismo de pesquisa distribuído, você pode usar vários nós / máquinas para gerenciar grandes quantidades de dados.
Todo índice de pesquisa elástica é composto de pelo menos um fragmento primário, pois é onde os dados são armazenados. Porém, todo shard tem um custo, portanto, se você tiver um único nó e nenhum crescimento previsível, fique com um único shard primário.
Outro tipo de fragmento é uma réplica. O padrão é 1, o que significa que todo shard primário será copiado para outro shard que conterá os mesmos dados. As réplicas são usadas para aumentar o desempenho da pesquisa e o failover. Um shard de réplica nunca será alocado no mesmo nó em que o primário relacionado está (seria como colocar um backup no mesmo disco que os dados originais).
De volta ao nosso exemplo, com 1 réplica, teremos o índice inteiro em cada nó, pois dois shards de réplica serão alocados no primeiro nó e conterão exatamente os mesmos dados que os shards primários no segundo nó:
____ ____ ____ ____ ____
| 1 | | 2 | | 3 | | 4R | | 5R |
|____| |____| |____| |____| |____|
O mesmo para o segundo nó, que conterá uma cópia dos shards primários no primeiro nó:
____ ____ ____ ____ ____
| 1R | | 2R | | 3R | | 4 | | 5 |
|____| |____| |____| |____| |____|
Com uma configuração como esta, se um nó cair, você ainda terá o índice inteiro. Os shards de réplica se tornarão primários automaticamente e o cluster funcionará corretamente, apesar da falha do nó, da seguinte maneira:
____ ____ ____ ____ ____
| 1 | | 2 | | 3 | | 4 | | 5 |
|____| |____| |____| |____| |____|
Como você possui "number_of_replicas":1, as réplicas não podem mais ser atribuídas, pois nunca são alocadas no mesmo nó onde está o principal. É por isso que você terá 5 shards não atribuídos, as réplicas e o status do cluster em YELLOWvez deGREEN . Sem perda de dados, mas poderia ser melhor, pois alguns shards não podem ser atribuídos.
Assim que o nó restante for copiado, ele ingressará no cluster novamente e as réplicas serão atribuídas novamente. O shard existente no segundo nó pode ser carregado, mas eles precisam ser sincronizados com os outros shards, pois as operações de gravação provavelmente ocorreram enquanto o nó estava inoperante. No final desta operação, o status do cluster se tornará GREEN.
Espero que isso esclareça as coisas para você.
