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