elasticsearch(es) 集群恢复触发配置（Local Gateway）
当你集群重启时，几个配置项影响你的分片恢复的表现。 首先，我们需要明白如果什么也没配置将会发生什么。
想象一下假设你有 10 个节点，每个节点只保存一个分片，这个分片是一个主分片或者是一个副本分片，或者说有一个有 5 个主分片／1 个副本分片的索引。有时你需要为整个集群做离线维护（比如，为了安装一个新的驱动程序）， 当你重启你的集群，恰巧出现了 5 个节点已经启动，还有 5 个还没启动的场景。
假设其它 5 个节点出问题，或者他们根本没有收到立即重启的命令。不管什么原因，你有 5 个节点在线上，这五个节点会相互通信，选出一个 master，从而形成一个集群。 他们注意到数据不再均匀分布，因为有 5 个节点在集群中丢失了，所以他们之间会立即启动分片复制。
最后，你的其它 5 个节点打开加入了集群。这些节点会发现 它们 的数据正在被复制到其他节点，所以他们删除本地数据（因为这份数据要么是多余的，要么是过时的）。 然后整个集群重新进行平衡，因为集群的大小已经从 5 变成了 10。
在整个过程中，你的节点会消耗磁盘和网络带宽，来回移动数据，因为没有更好的办法。对于有 TB 数据的大集群, 这种无用的数据传输需要 很长时间 。如果等待所有的节点重启好了，整个集群再上线，所有的本地的数据都不需要移动。
本地网关模块在整个集群重新启动时存储集群状态和分片数据。
以下参数是配置 尝试恢复集群状态和集群数据 的触发点，必须在每个主节点上都做做如下配置。
gateway.expected_nodes
预期在集群中的（数据或主）节点数。只要预期的节点数已加入集群，就会启动本地分片的恢复。默认为0
gateway.expected_master_nodes
预期在集群中的主节点数。一旦预期的主节点数加入集群，就会开始恢复本地分片。默认为0
gateway.expected_data_nodes
预期在集群中的数据节点数。一旦预期数量的节点已加入集群，就会启动本地分片的恢复。默认为0
gateway.recover_after_time
如果未达到预期的节点数，则恢复过程将等待配置的时间量，然后再尝试恢复。如果只要配置了expected_nodes，则默认这个参数值为5m
一旦recover_after_time持续时间超时，只要满足以下条件，恢复就会开始：
gateway.recover_after_nodes
只要此许多数据或主节点已加入集群，即可恢复。
gateway.recover_after_master_nodes
只要这么多主节点已加入集群，就可以恢复。
gateway.recover_after_data_nodes
只要这么多数据节点已加入集群，就可以恢复。
上述描述来自官方文档Local Gateway的描述，看完之后有点绕，还是不能完全理解。
stack overflow 上的解释
stack overflow 上的描述相对好理解很多：Difference between expected_nodes and recover_after_nodes parameters。这里做一下搬运工，给出结论。
满足 gateway.recover_* 条件之后会触发记时器，有两种情况
- 在
recovery_after_time 为用完，满足 gateway.excepted_* 条件则立即执行数据同步
-
recovery_after_time 时间用完，那么也会开始执行数据同步
举个栗子
gateway:
recover_after_nodes: 3
expected_nodes: 5
虽然上面没有配置 recovery_after_time 属性，但是因为配置了 expected_nodes 所以会有默认值 5m，就是5分钟。
假设集群中有5个node，其中3个node已经恢复正常使用，也就是达到了 recover_after_nodes: 3 的条件。那么如果5分钟之内一共有5个node恢复正常使用，那么会立即进行集群的数据恢复，要不然就是过了5分钟node数量打不到5个，也会触发数据恢复。
欢迎转载，但请注明本文链接，谢谢你。
2018.7.7 17:31
