ElasticSearch重启shard恢复过慢，集群状态一直恢复不了Green，影响权限刷新和数据使用

这个问题困扰我们很久，各种原因需要重启集群的时候需要等待很长时间，总要在休息时间做重启。
后来发现ElasticSearch中支持几个参数配置附上官网地址

	gateway.expected_nodes
	gateway.expected_master_nodes
	gateway.expected_data_nodes
	gateway.recover_after_time
	gateway.recover_after_nodes
	gateway.recover_after_master_nodes
	gateway.recover_after_data_nodes

下面一个一个的解释一下（代表个人理解）：

1. gateway.expected_nodes
   重启是集群间通过心跳发现有足够的节点上线后，开始进行数据恢复

2. gateway.expected_master_nodes
   和上一条基本相同不过这个参数限定了必须是master节点

3. gateway.expected_data_nodes
   和第一条基本相同不过这个参数限定了必须是data节点

4. gateway.recover_after_time
   这个参数从另一个维度进行了数据恢复的限定，配置等待时间，节点从上线到心跳交流有一个时间过程。如果在限定的时间内指定的node数量未达到，则集群开始等待5-7的条件，如果未设置则开始数据恢复。只要设置了任意一个expected_nodes参数，启用默认时间5m。和expected_nodes配置不冲突，那个配置的条件先达到那个配置就提前生效。

5. gateway.recover_after_nodes
   只要有足够的节点数量就开始恢复数据。足够就是此参数配置的值

6. gateway.recover_after_master_nodes
   只要有足够的master节点数量就开始恢复数据。足够就是此参数配置的值

7. gateway.recover_after_data_nodes
   只要有足够的data节点数量就开始恢复数据。足够就是此参数配置的值

至于为什么这么多的配置用于重启集群，还是和集群重启的过程有关系，如果上述参数均没有进行配置会出现下述情况（集群10个节点为例）：
恢复的过程中由于各种原因，只有其中五个启动，剩下五个节点在初始化的过程中。此处master和data不做区分。五个节点会根据选举机制选出一个master，并且组成一个小的es集群。这时就会出现一个很尴尬的情况，其中一部分数据的primary或者replica shard在另外五个没有启动的节点上，集群就会开始数据的自动回复和备份功能。具体的就是一些replica成为primary shard，并且为了维护index有足够的副本数量，开始对这部分数据进行移动和备份。
为了说明白，我们把情况说的极端点。直到这5个节点的集群数据恢复完了备份完了，另外五个几点才刚刚启动完成，通过心跳注册进了集群，但是这时集群发现之前的index数据多了replica shard和primary shard。就会对后启动的5个节点的数据进行删除，最后进行shard的rebalance操作。
上述过程在达到一定数据量的规模的时候，时间耗费尤为明显。

建议配置过程中只需配置
gateway.expected_nodes和gateway.recover_after_time nodes设置为集群node数量，时间稍微设置的长一点10m，足够集群进行全节点的启动。