1、背景
我们的ES集群四台机器发生了当机，而且是晚上当机，早上才发现，后来直接重启之后发现速度非常慢，基本上慢了一个数量级，周末查了一天没查到原因，晚上想了下，早上突然想起是不是shard分配造成的。
2、刨根求源
通过x-pack监控，按照索引速度按照速度排序，去找到正在入的主要索引，然后在cerebro去查询这个索引的shard分布情况，结果一看吓一跳，二十多个shard分布在几台节点上，我们一共是57个节点，每个主副本shard在一个节点上完全是够的。
2.1 为什么会出现这个问题
通过仔细观察发现集中shard的机器是重启的4台机器，后来才恍然大悟，机器是在夜里当机的，当机后，索引仍然可以正常创建，导致了剩下机器的shard数量比当机的4个机器要多很多，就导致了后面的shard尽量集中在这几台机器。
- 设置了只对主分配进行负载均衡。【后来设置为none关闭】
- 同时进行负载均衡的分片数量为4个。
- 当所有分片都是出于active的时候再进行负载均衡。
PUT _cluster/settings
{
"persistent" :
{
"cluster.routing.rebalance.enable": "primaries ",
"cluster.routing.allocation.cluster_concurrent_rebalance":4,
"cluster.routing.allocation.allow_rebalance":"indices_all_active"
}
}
2.2 如何解决这个问题
开始我是这样理解的，主副本平衡是关键，所以通过cerebro监控工具直接手工调节，后来也逐步完成了所有的在入索引的主shard的同步，结果仍然速度不快，后来了解到es和solr的入索引是一样的，都是先发给主shard，然后主shard再发给各个副本，各个副本将结果返回给主，最后再返回给客户端，显然我们的问题不光要控制主的负载均衡，还需要控制副本的整体均衡,没办法，先把副本改成0吧。
命令如下：
PUT /index_20180805*/_settings
{
"number_of_replicas": 0
}
2.3 新建索引指定节点
为了解决这个问题，开始我们做了新建其他没用的索引，且指定shard在固定的4台机器上，这样上面的shard就多了，后面创建的索引就不会过多地落在上面了，命令如下：
PUT /testshard3
{
"settings" : {
"number_of_shards":3,
"number_of_replicas" : 0,
"refresh_interval":"120s",
"index.routing.allocation.include._ip":"192.168.1.134"
}
}
3、另外问题
由于es对离开的节点立刻做了负载均衡，如果节点在很快的时间内返回的后，再进行一次rebalance是很不划算的，设置下在离开的多长时间之后再进行负载均衡：
PUT /_all/_settings
{
"settings": {
"index.unassigned.node_left.delayed_timeout": "720m"
}
对已经存在的index起作用，新的要重新运行。
这样应该就不会有很大的不平衡了。
4、参考
节点脱离了会发生什么：https://blog.csdn.net/zhengxgs/article/details/53942941
ES建索引过程：https://www.cnblogs.com/wenBlog/p/8489197.html
分片的分配过程：https://www.cnblogs.com/kasumi/p/6530535.html
5、同事找到一个办法
但是动态设置更改不起作用。
PUT /testshard4
{
"settings" : {
"number_of_shards":3,
"number_of_replicas" : 0,
"refresh_interval":"120s",
"index.routing.allocation.total_shards_per_node": 1
}
}
注意这里面有个坑，副本也算一个分配，如果你配置了30个shard，1个副本的话，那么机器数必须至少是60个才可以满足要求。
PUT /first*/_settings
{
"index": { "routing.allocation.total_shards_per_node" : "2" }
}
有大神有解决办法吗，请告知。
