新年第一天开工。兴致高高的来上班,想着拿个开门红包,红包没拿到。结果遇到了Elasticsearch有个索引状态为yellow。很好,很惊喜,perfect!
首先,介绍下个人理解的ES集群的三种状态:
- Green - 所有数据都可用,主副分片都已经分配好
- Yellow - 所有数据都可用,但尚未分配一些副本,不影响查询,可能影响恢复。
- Red - 某些数据由于某种原因 存在主分片未分配,对查询会有影响
虽然不影响查询,但是也要解决下这个问题。
问题排查:
使用es 运维命令
GET /_cluster/health?level=indices 查看集群的健康并显示索引状态
GET /_cat/allocation?v 查看集群中每个节点的分片分配情况,
unassigned_shards=5,确定是副本分片未分配,导致集群状态Yellow
GET /_cluster/allocation/explain 查看unassigned 的原因
查看每个节点原因 说有同样的数据,不能分配,这时候就考虑是分片未合理规划的原因了。
通过kibana 或者命令get /_cat/indices?v 查看 索引的分片规划 ,我这里是通过kibana
主分片5,副本分片5 ,但是总节点5 ,看上是挺合理的,总shard数是节点的整数倍。细致分析下 es的主副分片 不可能再同一node节点上,这样就出现了不能分配的原因。
既然想到了,肯定要验证下
GET _cat/shards?h=index,shard,prirep,state,unassigned.reason 查看
以上的0,1,2,3,4代表节点的编号,很清楚的可以看出 每个节点,一个p 4r,然后有一个r不能分配,证实了我们的分析原因。既然知道问题所在,就好解决,更改索引的副本数量
PUT /trademark_us_index/_settings
{
"number_of_replicas": 4
}
更改完后查询 GET /_cluster/health?level=indices
查看索引的主副本数量