难点！干货！经验证！生产Elasticsearch超大集群中如何让主分片(shards)均匀分布，且不需要重启服务？(详细分析原因和解决之道)

介绍，索引的主分片在es节点上分布不均匀

elasticsearch在实际生产应用中，经常由于es节点的上下线检修维护，或则由于索引设置的调整，常常会导致索引主分片和副本分片分布不均匀的问题。由于elasticsearch中主分片主要用于写操作，副本分片用于读操作，不均匀的主分片和副本分片分布，可能导致数据的读写性能不稳定或性能下降。
elasticsearch 索引的主分片(primary shard)和副本分片(replica shard)在每个节点上分布不均匀。

问题分析，什么问题导致分布不均匀？

• 节点上下线
  通常在下线一个es节点后，下线节点上存在的主分片会被检测掉丢失，elasticsearch集群会自动将其他节点上的副本分片设置为主分片，当该下线节点被重新拉起时，分片数据被识别，但均会被识别为副本分片。这些操作会导致一些节点的主分片比较集中，一些节点上的副本分片比较集中。
• 大量较为集中的数据写入
  大量的数据集中写入，可能导致暂时的主分片不均匀的情况。当业务场景为写入较多时，设置了较多的ingest节点进行写入，由于无法及时同步，导致主分片节点较为集中。

tips: elasticsearch节点的主分片分布不均匀是否需要进行人为干预，取决于自己的业务场景，若仅有个别节点如此，则不会影响应用，可不进行干预。

• 解决思路：
  备份数据后，将副本数设置为0，主分片重新分配后，恢复副本分片数。
  不适用范围：此方案用于主分片分布不均，不解决主分片和副本分片分布的问题，若要解决此问题，设置total_shards_per_node即可。

解决方案

其他方式：也可通过重启集群，重建索引等方式解决。

步骤一、备份数据(若有备份，可忽略)

备份数据是为了保证生产数据操作失误时，可及时通过别名映射，不至于数据丢失或影响业务应用。

# 备份索引数据
POST /_reindex?slices=20&timeout=100000s
{"source":{"index":"索引名","size":10000},"dest":{"index":"索引名"-copy-年月日"}
}# 查看备份数据
GET /索引名-copy-年月日# 重建索引的副本数默认为1，如果觉得不太稳，最好将副本数设置为2,待副本集完全复制后操作后续步骤
PUT /索引名-copy-年月日/_settings
{"number_of_replicas": 2
}

若不担心数据丢失，设置副本数步骤可忽略

步骤二、更改索引副本数

删除索引副本，让主分片均匀分布在各个节点

# 设置原有数据副本数为0
PUT /索引名/_settings
{"number_of_replicas": 0
}

操作前：
elasticsearch 索引的主分片没有均匀分布在es节点上

操作后：
elasticsearch 索引的主分片均匀分布在es节点上,但没有副本分片

步骤三、恢复索引副本集

# 重新设置副本集数量
PUT /索引名/_settings
{"number_of_replicas": 2
}

操作后：
elasticsearch 索引的主分片均匀分布在es节点上,副本分片也均匀分布在各个es节点上

至此，问题完美解决。遵循生产集群操作规范，因此需要格外谨慎。若大家有不同的问题，或更好的解决办法，欢迎大家补充。

参考链接

elasticsearch cluster reroute api 官方文档