应对故障
我们已经说过Elasticsearch可以应对节点失效，所以让我们继续尝试。如果我们杀掉第一个节点的进程（以下简称杀掉节点），看起来像如此：
我们杀掉的节点是一个主节点。必须有一个主节点来让集群的功能可用，所以发生的第一件事就是各节点选举了一个新的主节点：Node 2。
主分片1和2在我们杀掉Node 1时已经丢失，我们的索引在丢失主节点时不能正常工作。如果此时我们检查集群健康，我们将看到状态red：不是所有主节点都可用！
幸运的是丢失的两个主分片的完整拷贝在其他节点上还存在，所以新主节点的第一件事是提升这些在Node 2和Node 3上的分片的副本为主分片，集群健康回到yellow状态。这个提升是瞬间完成的，就好像按了一下开关。
为什么集群健康状态是yellow而不是green？我们有三个主分片，但是我们指定了每个主分片对应两个复制分片，当前却只有一个被定义。这阻止我们达到green状态，不过不用太担心这个：当我们杀掉Node 2，我们的程序依旧可以在没有丢失数据的情况下运行，因为Node 3还有每个分片的拷贝。
如果我们重启Node 1，集群将能够分配丢失的复制分片，结果状态与三主节点双复制一致。如果Node 1依旧有旧节点的拷贝，它将会尝试再利用它们，它只会复制在故障期间数据变更的部分。
现在你应该对分片如何使Elasticsearch可以水平扩展并保证数据安全有了一个清晰的认识。接下来我们将会讨论分片生命周期的更多细节。