Elasticsearch学习之集群常见状况处理(干货)

Posted sunfie

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Elasticsearch学习之集群常见状况处理(干货)相关的知识,希望对你有一定的参考价值。

1. 集群健康状况处理

当集群处于yellow或者red状态的时候,整体处理步骤如下:

(1) 首先查看集群状态

localhost:9200/_cluster/health?pretty


  "cluster_name": "elasticsearch",
  "status": "yellow",
  "timed_out": false,
  "number_of_nodes": 1,
  "number_of_data_nodes": 1,
  "active_primary_shards": 278,
  "active_shards": 278,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 278,
  "delayed_unassigned_shards": 0,
  "number_of_pending_tasks": 0,
  "number_of_in_flight_fetch": 0,
  "task_max_waiting_in_queue_millis": 0,
  "active_shards_percent_as_number": 50

主要关注其中的unassigned_shards指标,其代表已经在集群状态中存在的分片,但是实际在集群里又找不着。通常未分配分片的来源是未分配的副本。比如,一个有 5 分片和 1 副本的索引,在单节点集群上,就会有 5 个未分配副本分片。如果你的集群是 red 状态,也会长期保有未分配分片(因为缺少主分片)。其他指标解释:

(1) initializing_shards 是刚刚创建的分片的个数。比如,当你刚创建第一个索引,分片都会短暂的处于 initializing 状态。这通常会是一个临时事件,分片不应该长期停留在 initializing 状态。你还可能在节点刚重启的时候看到 initializing 分片:当分片从磁盘上加载后,它们会从 initializing 状态开始。

(2) number_of_nodes 和 number_of_data_nodes 这个命名完全是自描述的。

(3) active_primary_shards 指出你集群中的主分片数量。这是涵盖了所有索引的汇总值。

(4) active_shards 是涵盖了所有索引的_所有_分片的汇总值,即包括副本分片。

(5) relocating_shards 显示当前正在从一个节点迁往其他节点的分片的数量。通常来说应该是 0,不过在 Elasticsearch 发现集群不太均衡时,该值会上涨。比如说:添加了一个新节点,或者下线了一个节点。

(2)查找问题索引

curl -XGET localhost:9200/_cluster/health?level=indices


    "cluster_name": "elasticsearch",
    "status": "yellow",
    "timed_out": false,
    "number_of_nodes": 1,
    "number_of_data_nodes": 1,
    "active_primary_shards": 278,
    "active_shards": 278,
    "relocating_shards": 0,
    "initializing_shards": 0,
    "unassigned_shards": 278,
    "delayed_unassigned_shards": 0,
    "number_of_pending_tasks": 0,
    "number_of_in_flight_fetch": 0,
    "task_max_waiting_in_queue_millis": 0,
    "active_shards_percent_as_number": 50,
    "indices": 
        "gaczrk": 
            "status": "yellow",
            "number_of_shards": 5,
            "number_of_replicas": 1,
            "active_primary_shards": 5,
            "active_shards": 5,
            "relocating_shards": 0,
            "initializing_shards": 0,
            "unassigned_shards": 5
        ,
        "special-sms-extractor_zhuanche_20200204": 
            "status": "yellow",
            "number_of_shards": 5,
            "number_of_replicas": 1,
            "active_primary_shards": 5,
            "active_shards": 5,
            "relocating_shards": 0,
            "initializing_shards": 0,
            "unassigned_shards": 5
        ,
        "specialhtl201905": 
            "status": "yellow",
            "number_of_shards": 1,
            "number_of_replicas": 1,
            "active_primary_shards": 1,
            "active_shards": 1,
            "relocating_shards": 0,
            "initializing_shards": 0,
            "unassigned_shards": 1
        ,
        "v2": 
         "status": "red", 
"number_of_shards": 10,
"number_of_replicas": 1,
"active_primary_shards": 0,
"active_shards": 0,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 20
,
       "sms20181009":  
"status": "yellow",
"number_of_shards": 5,
"number_of_replicas": 1,
"active_primary_shards": 5,
"active_shards": 5,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 5
,
......

这个参数会让 cluster-health API 在我们的集群信息里添加一个索引清单,以及有关每个索引的细节(状态、分片数、未分配分片数等等),一旦我们询问要索引的输出,哪个索引有问题立马就很清楚了:v2 索引。我们还可以看到这个索引曾经有 10 个主分片和一个副本,而现在这 20 个分片全不见了。可以推测,这 20 个索引就是位于从我们集群里不见了的那两个节点上。一般来讲,Elasticsearch是有自我分配节点功能的,首先查看这个功能是否开启:

curl -XGET localhost:9200/_cluster/settings?pretty -d  

    "persistent": ,
    "transient": 
        "cluster": 
            "routing": 
                "allocation": 
                    "enable": "all"
                
            
        
    

level 参数还可以接受其他更多选项:

localhost:9200/_cluster/health?level=shards


    "cluster_name": "elasticsearch",
    "status": "yellow",
    "timed_out": false,
    "number_of_nodes": 1,
    "number_of_data_nodes": 1,
    "active_primary_shards": 278,
    "active_shards": 278,
    "relocating_shards": 0,
    "initializing_shards": 0,
    "unassigned_shards": 278,
    "delayed_unassigned_shards": 0,
    "number_of_pending_tasks": 0,
    "number_of_in_flight_fetch": 0,
    "task_max_waiting_in_queue_millis": 0,
    "active_shards_percent_as_number": 50,
    "indices": 
        "gaczrk": 
            "status": "yellow",
            "number_of_shards": 5,
            "number_of_replicas": 1,
            "active_primary_shards": 5,
            "active_shards": 5,
            "relocating_shards": 0,
            "initializing_shards": 0,
            "unassigned_shards": 5,
            "shards": 
                "0": 
                    "status": "yellow",
                    "primary_active": true,
                    "active_shards": 1,
                    "relocating_shards": 0,
                    "initializing_shards": 0,
                    "unassigned_shards": 1
                ,
                "1": 
                    "status": "yellow",
                    "primary_active": true,
                    "active_shards": 1,
                    "relocating_shards": 0,
                    "initializing_shards": 0,
                    "unassigned_shards": 1
                ,
                "2": 
                    "status": "yellow",
                    "primary_active": true,
                    "active_shards": 1,
                    "relocating_shards": 0,
                    "initializing_shards": 0,
                    "unassigned_shards": 1
                ,
                "3": 
                    "status": "yellow",
                    "primary_active": true,
                    "active_shards": 1,
                    "relocating_shards": 0,
                    "initializing_shards": 0,
                    "unassigned_shards": 1
                ,
                "4": 
                    "status": "yellow",
                    "primary_active": true,
                    "active_shards": 1,
                    "relocating_shards": 0,
                    "initializing_shards": 0,
                    "unassigned_shards": 1
                
            
        ,
......

shards 选项会提供一个详细得多的输出,列出每个索引里每个分片的状态和位置。这个输出有时候很有用,但是由于太过详细会比较难用。

(3) 手动分配未分配分片

查询未分配分片的节点以及未分配原因

localhost:9200/_cat/shards?v&h=index,shard,prirep,state,unassigned.reason

index                                   shard prirep state      unassigned.reason 
gaczrk                                  4     p      STARTED                      
gaczrk                                  4     r      UNASSIGNED CLUSTER_RECOVERED 
gaczrk                                  2     p      STARTED                      
gaczrk                                  2     r      UNASSIGNED CLUSTER_RECOVERED 
gaczrk                                  1     p      STARTED 

未分配原因说明:

INDEX_CREATED:  由于创建索引的API导致未分配。
CLUSTER_RECOVERED:  由于完全集群恢复导致未分配。
INDEX_REOPENED:  由于打开open或关闭close一个索引导致未分配。
DANGLING_INDEX_IMPORTED:  由于导入dangling索引的结果导致未分配。
NEW_INDEX_RESTORED:  由于恢复到新索引导致未分配。
EXISTING_INDEX_RESTORED:  由于恢复到已关闭的索引导致未分配。
REPLICA_ADDED:  由于显式添加副本分片导致未分配。
ALLOCATION_FAILED:  由于分片分配失败导致未分配。
NODE_LEFT:  由于承载该分片的节点离开集群导致未分配。
REINITIALIZED:  由于当分片从开始移动到初始化时导致未分配(例如,使用影子shadow副本分片)。
REROUTE_CANCELLED:  作为显式取消重新路由命令的结果取消分配。
REALLOCATED_REPLICA:  确定更好的副本位置被标定使用,导致现有的副本分配被取消,出现未分配。
 

然后执行命令手动分配: 

curl -XPOST localhost:9200/_cluster/reroute -d 
    "commands": [
        "allocate": 
            "index": "gaczrk(索引名称)",
            "shard": 4分片编号),
            "node": "其他node的id",
            "allow_primary": true
        
    ]

如果未分片较多的话,可以用如下脚本进行自动分派:

#!/bin/bash
array=( node1 node2 node3 )
node_counter=0
length=$#array[@]
IFS=$\n
for line in $(curl -s http://127.0.0.1:9200/_cat/shards|  fgrep UNASSIGNED); do
    INDEX=$(echo $line | (awk print $1))
    SHARD=$(echo $line | (awk print $2))
    NODE=$array[$node_counter]
    echo $NODE
    curl -XPOST http://127.0.0.1:9200/_cluster/reroute -d 
        "commands": [
        
            "allocate": 
                "index": "‘$INDEX‘",
                "shard": $SHARD,
                "node": "‘$NODE‘",
                "allow_primary": true
            
        
        ]
        node_counter=$(((node_counter)%length +1))
done

(4) 快速分配分片

在上面的命令执行输出结果中,假如所有的primary shards都是好的,所有replica shards有问题,有一种快速恢复的方法,就是强制删除掉replica shards,让elasticsearch自主重新生成。 首先先将出问题的index的副本为0

curl -XPUT /问题索引名称/_settings?pretty -d "index" : 
        "number_of_replicas" : 0
    

然后观察集群状态,最后通过命令在恢复期索引副本数据

curl -XGET /问题索引名称/_settings

    "index" : 
        "number_of_replicas" : 1
    

等待节点自动分配后,集群成功恢复成gree

(5)集群分片始终处于 INITIALIZING状态

curl -XGET localhost:9200/_cat/shards/7a_cool?v&pretty

7a_cool 5  r STARTED      4583018 759.4mb 10.2.4.21 pt01-pte-10-2-4-21
7a_cool 17 r INITIALIZING                 10.2.4.22 pt01-pte-10-2-4-22  《==异常分片

解决办法:

1)首先关闭异常分片主机es 服务;

登陆pt01-pte-10-2-4-22 主机  ,/etc/init.d/elasticsearch  stop 
如果分片自动迁移至其它主机,状态恢复,则集群正常,如果状态还是在初始化状态,则说明问题依旧存在;则执行上面手动分配分片命令,如果问题依然存在,则将问题索引分片副本数置为0,让集群
自主调整集群分片,调整完成后集群状态变成:green

以上是关于Elasticsearch学习之集群常见状况处理(干货)的主要内容,如果未能解决你的问题,请参考以下文章

Elasticsearch学习之Java操作1

Elasticsearch 学习之携程机票ElasticSearch集群运维驯服记(强烈推荐)

Elasticsearch 学习之不停止服务,完成升级重启维护操作

SpringCloud学习之Ribbon

Elasticsearch聚合学习之四:结果排序

Elasticsearch学习之入门