• ES 遇到 unassigned shard如何处理?


    解决方法:(1)如果是红色的,可以直接分片shard给你认为有最新(或最多)数据的节点。见下:

    摘自:https://discuss.elastic.co/t/how-to-resolve-the-unassigned-shards/87635

    Use the reroute command to assign the unassigned shard to a node.

    If your cluster is red then you probably have primary shards unassigned. The command below will allow you to reassign a shard that has gone "stale"(腐烂不新鲜的). This means that ES is not sure which copy of the shard has the most recent data and it will not assign one as primary because if another shard with newer data connects to the cluster later it will be overwritten. If your confident that the shard has all of the data you need then you can assign it to a node with the command below. Just be wary of data loss。

    curl -XPOST 'localhost:9200/_cluster/reroute?pretty' -H 'Content-Type: application/json' -d'
    {
    "commands" : [
    {
    "allocate_stale_primary" : {
    "index" : "test", "shard" : 1,
    "node" : "node3",
    "accept_data_loss" : true
    }
    }
    ]
    }
    '
    https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-reroute.html

    (2)如果集群是黄色的,可以等其恢复

    The status may be one of three values:

    green
    All primary and replica shards are allocated. Your cluster is 100% operational.
    yellow
    All primary shards are allocated, but at least one replica is missing. No data is missing, so search results will still be complete. However, your high availability is compromised to some degree. If moreshards disappear, you might lose data. Think of yellow as a warning that should prompt investigation.
    red
    At least one primary shard (and all of its replicas) is missing. This means that you are missing data: searches will return partial results, and indexing into that shard will return an exception.

    The green/yellow/red status is a great way to glance at your cluster and understand what’s going on. The rest of the metrics give you a general summary of your cluster:

    • number_of_nodes and number_of_data_nodes are fairly self-descriptive.
    • active_primary_shards indicates the number of primary shards in your cluster. This is an aggregate total across all indices.
    • active_shards is an aggregate total of all shards across all indices, which includes replica shards.
    • relocating_shards shows the number of shards that are currently moving from one node to another node(现网中遇到,因为kill -9重启es的方法不对,导致node下线,集群重新分配shard). This number is often zero, but can increase when Elasticsearch decides a cluster is not properly balanced, a new node is added, or a node is taken down, for example(原因).
    • initializing_shards is a count of shards that are being freshly created. For example, when you first create an index, the shards will all briefly reside in initializing state. This is typically a transient event, and shards shouldn’t linger in initializing too long. You may also see initializing shards when a node is first restarted: as shards are loaded from disk, they start as initializing.(现网遇到过)
    • unassigned_shards are shards that exist in the cluster state, but cannot be found in the cluster itself. A common source of unassigned shards are unassigned replicas. For example, an index with five shards and one replica will have five unassigned replicas in a single-node cluster. Unassigned shards will also be present if your cluster is red (since primaries are missing).

    Drilling Deeper: Finding Problematic Indices

    Imagine something goes wrong one day, and you notice that your cluster health looks like this:

    {
       "cluster_name": "elasticsearch_zach",
       "status": "red",
       "timed_out": false,
       "number_of_nodes": 8,
       "number_of_data_nodes": 8,
       "active_primary_shards": 90,
       "active_shards": 180,
       "relocating_shards": 0,
       "initializing_shards": 0,
       "unassigned_shards": 20
    }

    OK, so what can we deduce from this health status? Well, our cluster is red, which means we are missing data (primary + replicas). We know our cluster has 10 nodes, but see only 8 data nodes listed in the health. Two of our nodes have gone missing. We see that there are 20 unassigned shards.

    That’s about all the information we can glean. The nature of those missing shards are still a mystery. Are we missing 20 indices with 1 primary shard each? Or 1 index with 20 primary shards? Or 10 indices with 1 primary + 1 replica? Which index?

    To answer these questions, we need to ask cluster-health for a little more information by using the level parameter:

    GET _cluster/health?level=indices

    This parameter will make the cluster-health API add a list of indices in our cluster and details about each of those indices (status, number of shards, unassigned shards, and so forth):

    {
       "cluster_name": "elasticsearch_zach",
       "status": "red",
       "timed_out": false,
       "number_of_nodes": 8,
       "number_of_data_nodes": 8,
       "active_primary_shards": 90,
       "active_shards": 180,
       "relocating_shards": 0,
       "initializing_shards": 0,
       "unassigned_shards": 20
       "indices": {
          "v1": {
             "status": "green",
             "number_of_shards": 10,
             "number_of_replicas": 1,
             "active_primary_shards": 10,
             "active_shards": 20,
             "relocating_shards": 0,
             "initializing_shards": 0,
             "unassigned_shards": 0
          },
          "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 
          },
          "v3": {
             "status": "green",
             "number_of_shards": 10,
             "number_of_replicas": 1,
             "active_primary_shards": 10,
             "active_shards": 20,
             "relocating_shards": 0,
             "initializing_shards": 0,
             "unassigned_shards": 0
          },
          ....
       }
    }

    We can now see that the v2 index is the index that has made the cluster red.

    And it becomes clear that all 20 missing shards are from this index.

    Once we ask for the indices output, it becomes immediately clear which index is having problems: the v2 index. We also see that the index has 10 primary shards and one replica, and that all 20 shards are missing. Presumably these 20 shards were on the two nodes that are missing from our cluster.

    摘自:https://www.elastic.co/guide/en/elasticsearch/guide/current/_cluster_health.html

  • 相关阅读:
    Linux运维之监控CPU和内存的日志工具
    Linux磁盘缓存的有趣实验
    Linux运维之内存分析2
    Linux运维之内存分析
    使用kubectl create 和 kubectl apply创建资源对象的区别
    Docker学习:Image的本地存储结构
    Docker 空间使用分析与清理
    HeidiSQL、Navicat、mysql命令和source命令导入sql脚本的速度比较
    Centos 7.2天兔(Lepus 3.8)数据库监控系统部署
    MegaCli 监控raid状态
  • 原文地址:https://www.cnblogs.com/bonelee/p/7458647.html
Copyright © 2020-2023  润新知