关于Elasticsearch集群Yellow状态的解释

2019年06月21日 |

Elasticsearch

| Elasticsearch

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

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

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）之后，我们在来看健康检查的结果：

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状态的方法，并尝试修复它。