正文

Elasticsearch学习之集群常见状况处理（干货）

IP云
IP云V管理员/0 阅读
11/29
小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

1. 集群健康状况处理

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

（1） 首先查看集群状态 

localhost:/_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": ,

    "number_of_data_nodes": ,

    "active_primary_shards": ,

    "active_shards": ,

    "relocating_shards": ,

    "initializing_shards": ,

    "unassigned_shards": ,

    "delayed_unassigned_shards": ,

    "number_of_pending_tasks": ,

    "number_of_in_flight_fetch": ,

    "task_max_waiting_in_queue_millis": ,

    "active_shards_percent_as_number": ,

    "indices": {

        "gaczrk": {

            "status": "yellow",

            "number_of_shards": ,

            "number_of_replicas": ,

            "active_primary_shards": ,

            "active_shards": ,

            "relocating_shards": ,

            "initializing_shards": ,

            "unassigned_shards":

        },

        "special-sms-extractor_zhuanche_20200204": {

            "status": "yellow",

            "number_of_shards": ,

            "number_of_replicas": ,

            "active_primary_shards": ,

            "active_shards": ,

            "relocating_shards": ,

            "initializing_shards": ,

            "unassigned_shards":

        },

        "specialhtl201905": {

            "status": "yellow",

            "number_of_shards": ,

            "number_of_replicas": ,

            "active_primary_shards": ,

            "active_shards": ,

            "relocating_shards": ,

            "initializing_shards": ,

            "unassigned_shards":

        },
        "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": , 
"number_of_replicas": , 
"active_primary_shards": , 
"active_shards": , 
"relocating_shards": , 
"initializing_shards": , 
"unassigned_shards":  
}, 
......

这个参数会让 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:/_cluster/health?level=shards

{

    "cluster_name": "elasticsearch",

    "status": "yellow",

    "timed_out": false,

    "number_of_nodes": ,

    "number_of_data_nodes": ,

    "active_primary_shards": ,

    "active_shards": ,

    "relocating_shards": ,

    "initializing_shards": ,

    "unassigned_shards": ,

    "delayed_unassigned_shards": ,

    "number_of_pending_tasks": ,

    "number_of_in_flight_fetch": ,

    "task_max_waiting_in_queue_millis": ,

    "active_shards_percent_as_number": ,

    "indices": {

        "gaczrk": {

            "status": "yellow",

            "number_of_shards": ,

            "number_of_replicas": ,

            "active_primary_shards": ,

            "active_shards": ,

            "relocating_shards": ,

            "initializing_shards": ,

            "unassigned_shards": ,

            "shards": {

                "": {

                    "status": "yellow",

                    "primary_active": true,

                    "active_shards": ,

                    "relocating_shards": ,

                    "initializing_shards": ,

                    "unassigned_shards":

                },

                "": {

                    "status": "yellow",

                    "primary_active": true,

                    "active_shards": ,

                    "relocating_shards": ,

                    "initializing_shards": ,

                    "unassigned_shards":

                },

                "": {

                    "status": "yellow",

                    "primary_active": true,

                    "active_shards": ,

                    "relocating_shards": ,

                    "initializing_shards": ,

                    "unassigned_shards":

                },

                "": {

                    "status": "yellow",

                    "primary_active": true,

                    "active_shards": ,

                    "relocating_shards": ,

                    "initializing_shards": ,

                    "unassigned_shards":

                },

                "": {

                    "status": "yellow",

                    "primary_active": true,

                    "active_shards": ,

                    "relocating_shards": ,

                    "initializing_shards": ,

                    "unassigned_shards":

                }

            }

        },

......

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

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

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

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

index                                   shard prirep state      unassigned.reason

gaczrk                                       p      STARTED

gaczrk                                       r      UNASSIGNED CLUSTER_RECOVERED

gaczrk                                       p      STARTED

gaczrk                                       r      UNASSIGNED CLUSTER_RECOVERED

gaczrk                                       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=

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 +))

done

(4) 快速分配分片

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

curl -XPUT '/问题索引名称/_settings?pretty' -d '{

    "index" : {

        "number_of_replicas" :

    }

}'

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

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

{

    "index" : {

        "number_of_replicas" :

    }

}

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

（5）集群分片始终处于 INITIALIZING状态 

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

7a_cool   r STARTED       .4mb 10.2.4.21 pt01-pte----

7a_cool  r INITIALIZING                 10.2.4.22 pt01-pte----  《==异常分片

解决办法：

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

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

相关阅读

目录[+]