Elasticsearch集群各个颜色区别和解决方案

Elasticsearch集群黄色原因的终极探秘

Elasticsearch集群颜色变黄解决方案(一)

---

前言

随着对ES的接触的加深，我们便会发现。其实，ES与Mysql等持久化数据库等等，如果从存储本质上来看的话。应该是没有本质上的区别的。我们进行的操作，也只有增删查改四个基本操作。ES也不会对我们的数据，默认的进行十分漂亮的操作，帮助我们完成十分漂亮的操作。

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、Elasticsearch集群不同颜色代表什么？

1. 绿色——最健康的状态，代表所有的主分片和副本分片都可用；
2. 黄色——所有的主分片可用，但是部分副本分片不可用；
3. 红色——部分主分片不可用。（此时执行查询部分数据仍然可以查到，遇到这种情况，还是赶快解决比较好。

二、Elasticsearch 集群颜色变黄色了要不要紧？

Elasticsearch集群黄色代表：

• 分配了所有主分片，但至少缺少一个副本。
• 没有数据丢失，因此搜索结果仍将完整。

注意：您的高可用性在某种程度上会受到影响。 如果更多分片消失，您可能会丢失数据。 将黄色视为应该提示调查的警告。

三、Elasticsearch集群健康状态如何排查？

1.集群状态查看

curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'  
{
 "cluster_name" : "astrung",
 "status" : "yellow",
 "timed_out" : false,
 "number_of_nodes" : 2,
 "number_of_data_nodes" : 2,
 "active_primary_shards" : 22,
 "active_shards" : 22,
 "relocating_shards" : 0,
 "initializing_shards" : 2,
 "unassigned_shards" : 20
}

2.分片状态查看

curl -XGET 'http://localhost:9200/_cat/shards?v'
 index          shard prirep state        docs  store ip          node 
 _river         0     p      STARTED         2  8.1kb 192.168.1.3 One  
 _river         0     r      UNASSIGNED                                
 megacorp       4     p      STARTED         1  3.4kb 192.168.1.3 One  
 megacorp       4     r      UNASSIGNED                                
 megacorp       0     p      STARTED         2  6.1kb 192.168.1.3 One  

3.查看unassigned 的原因

GET /_cluster/allocation/explain

4.查看集群中不同节点、不同索引的状态

GET _cat/shards?h=index,shard,prirep,state,unassigned.reason

5.Head插件直观排查

四、Elasticsearch集群黄色的原因排查及解决方案

原因1：Elasticsearch采用默认配置（5分片，1副本），但实际只部署了单节点集群。

由于只有一个节点，因此群集无法放置副本，因此处于黄色状态。
elasticsearch 索引的默认配置如下：

index.number_of_shards：5
index.number_of_replicas：1

解决方案如下：
您可以将副本计数降低到0或将第二个节点添加到群集，以便可以将主分片和副本分片安全地放在不同的节点上。
这样做以后，如果您的节点崩溃，群集中的另一个节点将拥有该分片的副本。
(1) 设置副本数为0，操作如下：

PUT /索引名字/_settings
{
  "number_of_replicas": 0
}

进行段合并，提升访问效率，操作如下：

POST /索引名字/_forcemerge?max_num_segments=1

(2) 不再物理扩展集群，将后续所有的索引自动创建的副本设置为 0。

PUT /_template/index_defaults 
{
  "template": "*", 
  "settings": {
  "number_of_replicas": 0
  }
}

原因2：Elasticsearch分配分片错误。

进一步可能的原因：您已经为集群中的节点数过分分配了副本分片的数量，则分片将保持UNASSIGNED状态。其错误码为：ALLOCATION_FAILED。
解决方案如下：
reroute：重新路由命令允许手动更改群集中各个分片的分配。
核心操作如下：

POST /_cluster/reroute
  {
  "commands": [
    {
      "allocate_replica": {
        "index": "cs_indexs",
        "shard": 0,   # 重新分配的分片（标记黄色的分片）
        "node": "es-2"
      }
    }
  ]
}

reroute扩展使用——可以显式地将分片从一个节点移动到另一个节点，可以取消分配，
并且可以将未分配的分片显式分配给特定节点。
举例使用模板如下：

POST /_cluster/reroute
{
    "commands" : [
        {
            "move" : {
                "index" : "test", "shard" : 0,
                "from_node" : "node1", "to_node" : "node2"
            }
        },
        {
          "allocate_replica" : {
                "index" : "test", "shard" : 1,
                "node" : "node3"
          }
        }
    ]
}

其中：

1. move代表移动；
2. allocate_replica 代表重新分配；
3. cancel 代表取消；

原因3：磁盘使用过载。

原因3：磁盘使用超过设定百分比85%。
cluster.routing.allocation.disk.watermark.low——控制磁盘使用的低水位线。 它默认为85％，这意味着Elasticsearch不会将分片分配给使用磁盘超过85％的节点。 它也可以设置为绝对字节值（如500mb），以防止Elasticsearch在小于指定的可用空间量时分配分片。
解决方案：
(1) 查看磁盘空间是否超过85%。

[root@localhost home]# df -h
Filesystem           Size  Used Avail Use% Mounted on
/dev/xvda1          1014M  165M  849M  17% /boot
/dev/mapper/cl-home  694G  597G   98G  86% /home

(2) 删除不必要的索引，以释放更多的空间。

DELETE  cs_indexs

原因4：磁盘路径权限问题。

原因4：磁盘路径权限问题。安全起见，默认Elasticsearch非root账户和启动。
相关的Elasticsearch数据路径也是非root权限。
解决方案：
去数据存储路径排查权限，或者在data的最外层设置：

chown -R elasticsearch:elasticsearch data

---

总结

如果发现es变黄了，请及时排查，不然很大可能性出现数据丢失的问题，不要问，问就是我们公司线上出过这个问题。