关于Elasticsearch集群Yellow状态的解释

在开始之前,让我来一起回顾一下Elasticsearch的术语:一个Elasticsearch的集群(cluster)是由一个或多个节点(node)组成的。每个节点(node)包含一个或多个索引(index),索引(index)又分离为多个分片(shard)。Elasticsearch把分片(shard)的拷贝叫做副本(replica)。这些分片(shard)和副本(replica)放置在集群的不同节点(node)上。

我们可以使用Cluster Health API来检查集群的健康状态:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
curl -XGET http://localhost:9200/_cluster/health?pretty=true

{
"cluster_name" : "asgard",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 5,
"active_shards" : 5,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 5
}

Elasticsearch提供了一个易用的集群健康分类,就像交通灯一样。这里做一个简单的解释:

  • RED: 糟糕。有部分或者全部主要分片(shard)没有准备好。
  • YELLOW:Elasticsearch放置好了所有的主要分片(shard),但是有一些或者所有的副本(replica)没有放置好。
  • GREEN: 很好。你的集群(cluster)完全在工作。Elasticsearch在组成集群(cluster)的机器上放置好了所有的分片(shard)和副本(replica)。

现在,我们的集群(cluster)健康状态是yellow, 意味着分片(shard)的副本(replica)没有被完全放置好。为什么会这样?因为当前的集群只有一个节点,所以副本(replica)保持在未分配的状态只是简单的由于没有其他节点(node)可以放置它们。我们可以通过添加另外一个节点到集群中来修复这个问题。这个新的节点(node)会加入到你的集群(cluster)中,然后Elasticsearch会开始放置副本(replica)到这个节点(node)里。当Elasticsearch完成复制,设置好了所有的副本(replica)之后,我们在来看健康检查的结果:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
curl -XGET http://localhost:9200/_cluster/health?pretty=true

{
"cluster_name":"asgard",
"status":"green",
"timed_out":false,
"number_of_nodes":2,
"number_of_data_nodes":2,
"active_primary_shards":5,
"active_shards":10,
"relocating_shards":0,
"initializing_shards":0,
"unassigned_shards":0
}

这个做一个关于yellow状态的解释:当一个集群(cluster)的状态是yellow的时候,除了你的副本(replica)没有满足规定的条件以外,所有的东西都OK。请求仍然可以被成功的处理,但是当你的服务器宕机的时候,你就有丢失数据的风险。除非你的集群(cluster)有足够的节点来存放副本(replica),或者你调整了索引(index)的副本(replica)设置,状态才会变为GREEN。

原文地址:http://chrissimpson.co.uk/elasticsearch-yellow-cluster-status-explained.html

这篇文章比较老了,新一些的版本的健康检查命令已经变成了/_cat/health?v了,不过这不重要,我们主要是学到分析yellow状态的方法,并尝试修复它。

加载评论框需要科学上网