【es】关于 cluster.routing.allocatio
对 es集群设置参数：
$ curl -X PUT http://xx.xx.xx.xx:9200/_cluster/settings?pretty -d '{"transient": {"cluster.routing.allocation.enable": "none"}}'
验证的结果是执行新建索引后，一直收不到返回值。
如果禁用分片分配后，是不是就不能新建索引了？
官方给的文档上并没有写用影响索引新建。
https://www.elastic.co/guide/en/elasticsearch/reference/5.6/shards-allocation.html
image.png
建新索引的过程要分配分片，你禁用分配分片了，自然无法新建索引。
已经分配了的分片只是不能再在节点间迁移，不会影响读写，可以重启。
新建是会有影响，你看官方的重启步骤，是先关闭 allocation，然后重启，然后再打开。
集群重启的时候关闭 allocation，是为了防止节点重启时，节点上的分片被重新分配，这个过程是很耗资源的，而且重启一般是很快完成的，当集群快速重启后，其上的分片大部分是可以直接分配来用的，这样也可以加速集群完成分片分配的速度，从而加速重启的速度。
重启本来就可以不影响业务，你不禁用一样不会影响业务，只是可能由于在节点下线的时候由于分片重新分配导致你从 yellow 到 green 的时间变长，从而导致整个重启的时间变长。
如果集群设置了 cluster.routing.allocation.enable:none，执行命令：
PUT test_index
{
"settings": {
"index":{
"number_of_replicas" : 0,
"number_of_shards": 1
}
}
}
此操作会阻塞直至超时。
这个时候，test_index 是创建成功了，但是test_index的分片无法分配，因此集群的状态会变成Red。
image.png
另外，cluster.routing.allocation.enable 和 cluster.routing.rebalance.enable 参数是有区别的：
cluster.routing.allocation.enable 设置成none，主要是影响集群中创建的索引无法进行分片分配，把分片分配到某个节点上去。
cluster.routing.rebalance.enable设置成none， 主要是影响集群中已有索引的分片不会rebalance到其他节点上去。
看官方文档关于ElasticSearch节点升级(或者说节点重启)的描述：
把 index.unassigned.node_left.delayed_timeout(默认是1分钟) 设置得大一点，因为关闭了一台节点，意味着在这台节点上的所有副本(既包括 primary 也包括replica)都没了，某些索引的副本就达不到number_of_replicas 指定的值了，那么ES会"复制"一个新的副本出来以满足：number_of_replicas 参数所配置的值。
但由于是重启节点，而不是真正的故障，因此，应该要避免这种复制操作。index.unassigned.node_left.delayed_timeout 可以推迟这种复制操作的发生。
Elasticseach的数据分片shard，在创建索引之后，在生命周期内就不可改变了，所以在索引开始创建的时候，要根据预估的数据规模合理的设置shard数目。
在集群中让shard分布均匀，可以有效的均衡集群负载，所以我们要尽量保证shard的在集群中分布均匀。
每个shard都有自己的编号，从0 到 N-1 。
p 就表示是主分片 primary shard
r 就表示是副本分片 replica shard
你可以通过如下命令查看索引分片、副本：
$ curl -XGET ‘http://192.168.1.1:9200/_cat/shards’
message 2 r STARTED 2261608 1.4gb 192.168.218.26 192.168.218.26
message 2 p STARTED 2261608 1.4gb 192.168.218.24 192.168.218.24
message 3 r STARTED 2258963 1.4gb 192.168.218.26 192.168.218.26
message 3 p STARTED 2258963 1.4gb 192.168.218.25 192.168.218.25
message 7 r STARTED 2264466 1.4gb 192.168.218.24 192.168.218.24
message 7 p STARTED 2264466 1.4gb 192.168.218.25 192.168.218.25
message 5 r STARTED 2260943 1.5gb 192.168.218.26 192.168.218.26
message 5 p STARTED 2260943 1.5gb 192.168.218.25 192.168.218.25
message 6 r STARTED 2263902 1.4gb 192.168.218.24 192.168.218.24
message 6 p STARTED 2263902 1.4gb 192.168.218.25 192.168.218.25
message 8 p STARTED 2255911 1.4gb 192.168.218.24 192.168.218.24
message 8 r STARTED 2255911 1.4gb 192.168.218.25 192.168.218.25
message 1 r STARTED 2259116 1.4gb 192.168.218.26 192.168.218.26
message 1 p STARTED 2259116 1.4gb 192.168.218.25 192.168.218.25
message 4 r STARTED 2262232 1.4gb 192.168.218.26 192.168.218.26
message 4 p STARTED 2262232 1.4gb 192.168.218.24 192.168.218.24
message 0 r STARTED 2260498 1.4gb 192.168.218.26 192.168.218.26
message 0 p STARTED 2260498 1.4gb 192.168.218.24 192.168.218.24
分片数和副本个数在创建索引的时候都可以设置，副本的个数在创建索引之后可以随时更改。
elasticsearch的shard分布是根据集群设置的比重进行分配的，你可以设置：
curl -XPUT ‘http://xx.xx.xx.xx:9200/_cluster/settings?pretty=true’ -d ‘{
“transient” : {
“cluster.routing.allocation.balance.shard” : 0.33
“cluster.routing.allocation.balance.index” : 0.33
“cluster.routing.allocation.balance.primary” : 0.34
“cluster.routing.allocation.balance.threshold” : 1
}
}’
elasticsearch内部计算公式是：
weightindex(node, index) = indexBalance * (node.numShards(index) – avgShardsPerNode(index))
weightnode(node, index) = shardBalance * (node.numShards() – avgShardsPerNode)
weightprimary(node, index) = primaryBalance * (node.numPrimaries() – avgPrimariesPerNode)
weight(node, index) = weightindex(node, index) + weightnode(node, index) + weightprimary(node, index)
如果计算最后的weight(node, index)大于threshold， 就会发生shard迁移。
在一个已经创立的集群里，shard的分布总是均匀的。
但是当你扩容节点的时候，你会发现，它总是先移动replica shard到新节点。
这样就导致新节点全部分布的全是副本，主shard几乎全留在了老的节点上。
cluster.routing.allocation.balance参数，比较难找到合适的比例。
建议一种方式是在扩容的时候，设置cluster.routing.allocation.enable=primaries，指只允许移动主shard。
当你发现shard数已经迁移了一半的时候，改回cluster.routing.allocation.enable=all，这样后面的全迁移的是副本shard。
扩容之后，shard和主shard的分布还是均匀的。
参考
ElasticSearch集群shard均衡策略
https://zhuanlan.zhihu.com/p/164970344
Elasticseach日常维护之shard管理
https://zhaoyanblog.com/archives/687.html
Elasticsearch Guide [7.17]› Upgrade Elasticsearch/Full cluster restart upgrade
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/restart-upgrade.html
Elastic Docs› Elasticsearch Reference [5.6]› Modules› Cluster/Cluster Level Shard Allocation
https://www.elastic.co/guide/en/elasticsearch/reference/5.6/shards-allocation.html#shards-allocation
