shard recovery和shard重分配

在集群重启的时候，有一些配置会影响shard恢复过程。

如果有10个node，每个node都有一个shard，可能是primary shard或者是replica shard。当前index有5个primary shard，每个primary shard有一个replica shard。

默认配置下,shard恢复过程如下

当集群遇到重启情况时，节点是一个一个启动的，可能会出现5个节点先启动，剩下的5个没启动。启动的5个节点通过gossip协议相互通信，选举出一个master，组成集群。因为有5个节点尚未启动成功，那么未启动成功的节点上的shard是不可用的，集群少了一半的shard。此时启动成功的5个节点组成的集群开始将部分replica shard提升为primary shard，同时为每一个primary shard复制足够的replica shard。

如果将未启动成功的节点再次启动并成功加入集群后发现，本来是自己持有的shard已经被复制到之前启动成功的5个node上了。那么后面加入的5个node会删除本地的shard。

集群开始对shard进行reblance，将最早启动的5个node上的shard均匀发布到后来的5个node上。

劣势：shard重新复制，移动，删除，再次移动，会消耗大量网络资源和磁盘资源。对于数据量大的集群，重启时可能有TB级别的数据在移动，导致集群启动耗时很长。

此时修改配置改进，

gateway.recover_after_nodes: 8    //es等到8个node上线再开始shard recovery

gateway.expected_nodes: 10     //10个节点10在线

gateway.recover_after_time: 5m    //等待最多5分钟

经过上面配置后，es集群会等待至少8个节点在线，或等待5分钟或者10个节点都在线，开始shard recovery的过程。