当某个节点由于任何原因有意识或者无意识的离开集群时，主节点将通过以下方式进行响应：
•提升副本分片为主分片来替换节点中的任何主分片
•分配副本分片以替换丢失的副本（假设有足够的节点）。
•分片再平衡，均匀地分配到其余节点。
这些行为的目的是通过确保每个分片尽可能快地完全复制来保护集群防止数据丢失。
即使我们在节点级别和集群级别都调节并发恢复，这种“shard-shuffle”仍然可以在集群上施加大量额外的负载，如果丢失的节点可以很快重新加入集群，这可能不是必需的。想象这种情况：
•节点5丢失网络连接。
•主节点提升节点5中的所有主分片的副本分片成为主分片。
•主节点分配新的副本到集群中的其他节点。
•每个新副本通过网络获取主分片的整体复制。
•更多的分片被移动到不同的节点使集群再平衡。
•几分钟后节点5重新回到集群中。
•主节点通过分配分片到节点5使集群再平衡。
如果主节点等待几分钟，那么丢失的分片可能消耗比较少的网络流量来重新分配给节点5。对于已自动同步刷新的空闲分片（分片未接收索引请求），此过程将更加快速。
由于节点已经离开而成为未分配的副本分片的分配可以使用index.unassigned.node_left.delayed_timeout动态设置进行延迟，默认为1m。
可以在活动索引（或所有索引）上更新此设置：
PUT _all/_settings
{
"settings": {
"index.unassigned.node_left.delayed_timeout": "5m"
}
}
启用延迟分配后，上述情况会变成这样：
•节点5丢失网络连接。
•主节点提升节点5中的所有主分片的副本分片成为主分片。
•主节点纪录未分配的分片已被延时以及延时时间。
•由于存在未分配的副本分片，集群状态仍为黄色。
•节点5在延时超时之前加入集群。
•丢失的副本被重新分配给节点5（并且同步刷新的分片几乎立即恢复）。
注意
此设置不会影响主分片的副本分片的提升，也不会影响之前未分配的副本分片的分配。 值得一提的是，在整个集群重新启动后，延迟分配不会生效。 另外，如果主节点发生故障切换，过去设置的延迟时间将会清零（即复位到完整的初始延迟）。
如果延时分配超时，主节点会开始恢复缺失分片到另一个节点。如果缺失节点重新加入集群中，并且它的主分片仍热有相同的同步ID，分片移动会被取消并且同步分片会用于恢复。
由于这个原因，默认的 timeout 设置为一分钟：即使分片开始移动，取消恢复同步分片的花销也是小的。
分配被延时的分片数量可以通过集群健康接口查看：
GET _cluster/health #1
| 1 | 此请求将返回一个delayed_unassigned_shards值 |
如果一个节点不会返回集群并且希望Elasticsearch立即分配丢失的分片，只需要设置超时为零：
PUT _all/_settings
{
"settings": {
"index.unassigned.node_left.delayed_timeout": "0"
}
}
一旦丢失的分片开始恢复，就可以重置超时。