新年第一天开工。兴致高高的来上班，想着拿个开门红包，红包没拿到。结果遇到了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
查看索引的主副本数量
