介绍，索引的主分片在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节点上
至此，问题完美解决。遵循生产集群操作规范，因此需要格外谨慎。若大家有不同的问题，或更好的解决办法，欢迎大家补充。