我将尝试用一个真实的例子来解释，因为您得到的答案和答复似乎对您没有帮助。

当您下载并启动elasticsearch时，您将创建一个elasticsearch节点，该节点尝试加入现有集群（如果可用）或创建一个新集群。假设您使用一个节点（刚启动的一个节点）创建了自己的新集群。我们没有数据，因此我们需要创建一个索引。

创建索引时（在索引第一个文档时也会自动创建索引），您可以定义它将组成多少个分片。如果您不指定数字，它将具有默认的分片数量：5个原色。这是什么意思？

这意味着elasticsearch将创建5个包含您的数据的主要分片：

 ____    ____    ____    ____    ____
| 1  |  | 2  |  | 3  |  | 4  |  | 5  |
|____|  |____|  |____|  |____|  |____|

每次您为文档建立索引时，elasticsearch都会决定应该使用哪个主碎片来保存该文档，并在其中建立索引。主碎片不是数据的副本，而是数据！拥有多个分片确实有助于在一台机器上利用并行处理，但是要点是，如果我们在同一集群上启动另一个Elasticsearch实例，这些分片将以均匀的方式分布在集群上。

然后，节点1将仅保留三个分片：

 ____    ____    ____ 
| 1  |  | 2  |  | 3  |
|____|  |____|  |____|

由于剩余的两个分片已移至新启动的节点：

 ____    ____
| 4  |  | 5  |
|____|  |____|

为什么会这样？由于elasticsearch是一个分布式搜索引擎，因此您可以利用多个节点/机器来管理大量数据。

每个Elasticsearch索引都至少包含一个主分片，因为这是存储数据的地方。但是，每个分片都是有代价的，因此，如果您只有一个节点并且没有可预见的增长，则只需坚持使用一个主分片。

分片的另一种类型是副本。默认值为1，这意味着每个主分片将被复制到另一个包含相同数据的分片。副本用于提高搜索性能和故障转移。副本碎片永远不会分配到相关主数据库所在的同一节点上（这就像将备份与原始数据放在同一磁盘上一样）。

回到我们的示例，对于1个副本，我们将在每个节点上拥有整个索引，因为将在第一个节点上分配2个副本分片，并且它们将包含与第二个节点上的主分片完全相同的数据：

 ____    ____    ____    ____    ____
| 1  |  | 2  |  | 3  |  | 4R |  | 5R |
|____|  |____|  |____|  |____|  |____|

与第二个节点相同，它将包含第一个节点上的主要分片的副本：

 ____    ____    ____    ____    ____
| 1R |  | 2R |  | 3R |  | 4  |  | 5  |
|____|  |____|  |____|  |____|  |____|

通过这样的设置，如果节点发生故障，您仍然拥有整个索引。副本分片将自动成为主副本，并且即使节点发生故障，群集也可以正常工作，如下所示：

 ____    ____    ____    ____    ____
| 1  |  | 2  |  | 3  |  | 4  |  | 5  |
|____|  |____|  |____|  |____|  |____|

由于您具有"number_of_replicas":1，因此无法再分配副本，因为它们永远不会在其主副本所在的同一节点上进行分配。因此，您将拥有5个未分配的分片，副本和集群状态YELLOW为GREEN。没有数据丢失，但是由于不能分配某些分片，因此可能会更好。

一旦备份了剩下的节点，它将再次加入群集，并且副本将再次分配。可以加载第二个节点上的现有分片，但它们需要与其他分片同步，因为写操作最有可能在节点关闭时发生。该操作结束时，群集状态将变为GREEN。

希望这可以为您澄清一切。