时间戳

首页 > 解决方案 > ElasticSearch 节点故障

amazon-web-services - ElasticSearch 节点故障

问题描述

我的 Elasticsearch 集群从 2B 文档下降到 900M 记录，在 AWS 上它显示

重定位分片：4

显示时

活跃碎片：35

和

活跃的主分片：34

（可能不相关，但这里是其余的统计数据）：

节点数：9

数据节点数：6

未分配的分片：17

跑步时

GET /_cluster/allocation/explain

它返回：

{
  "index": "datauwu",
  "shard": 6,
  "primary": true,
  "current_state": "unassigned",
  "unassigned_info": {
    "reason": "NODE_LEFT",
    "at": "2019-10-31T17:02:11.258Z",
    "details": "node_left[removedforsecuritybecimparanoid1]",
    "last_allocation_status": "no_valid_shard_copy"
  },
  "can_allocate": "no_valid_shard_copy",
  "allocate_explanation": "cannot allocate because a previous copy of the primary shard existed but can no longer be found on the nodes in the cluster",
  "node_allocation_decisions": [
    {
      "node_id": "removedforsecuritybecimparanoid2",
      "node_name": "removedforsecuritybecimparanoid2",
      "node_decision": "no",
      "store": {
        "found": false
      }
    },
    {
      "node_id": "removedforsecuritybecimparanoid3",
      "node_name": "removedforsecuritybecimparanoid3",
      "node_decision": "no",
      "store": {
        "found": false
      }
    },
    {
      "node_id": "removedforsecuritybecimparanoid4",
      "node_name": "removedforsecuritybecimparanoid4",
      "node_decision": "no",
      "store": {
        "found": false
      }
    },
    {
      "node_id": "removedforsecuritybecimparanoid5",
      "node_name": "removedforsecuritybecimparanoid5",
      "node_decision": "no",
      "store": {
        "found": false
      }
    },
    {
      "node_id": "removedforsecuritybecimparanoid6",
      "node_name": "removedforsecuritybecimparanoid6",
      "node_decision": "no",
      "store": {
        "found": false
      }
    },
    {
      "node_id": "removedforsecuritybecimparanoid7",
      "node_name": "removedforsecuritybecimparanoid7",
      "node_decision": "no",
      "store": {
        "found": false
      }
    }
  ]
}

我对这到底意味着什么有点困惑，这是否意味着我的弹性搜索集群没有丢失数据，而是将其重新定位到不同的分片中，或者它找不到分片？

如果它找不到分片，这是否意味着我的数据丢失了？如果是这样，可能是什么原因，我怎样才能防止这种情况在未来发生？

我没有设置副本，因为我正在索引数据，并且副本在索引时会减慢它的速度。

同样，我的记录数一度下降到 400m，但随后又随机回升至 900m。我不知道这意味着什么，任何见解将不胜感激。

标签： amazon-web-serviceselasticsearch

解决方案

“原因”：“NODE_LEFT”

和：

我没有设置副本，因为我正在索引数据，并且副本在索引时会减慢它的速度。

如果持有主分片的节点已经消失，那么是的，你的数据已经消失了。毕竟，如果没有副本，那么如果主（也是唯一的）分片不再是集群的一部分，那么集群将从哪里检索数据？您要么需要恢复保存这些分片的节点并将其添加到集群中，要么数据消失。

错误消息是“您希望我为我知道存在的该索引分配一个主分片，但曾经有另一个版本的该主分片无法再找到，我不会再分配它以防万一以前的初选回来了。”

allocate_stale_primary您可以通过使用( doc )执行重新路由来强制 Elasticsearch 重新分配主分片（并明确接受前一个主分片中的数据已消失）：

curl -H 'Content-Type: application/json' \
    -XPOST '127.0.0.1:9200/_cluster/reroute?pretty' -d '{
    "commands" : [ {
        "allocate_stale_primary" :
            {
              "index" : "datauwu", "shard" : 6,
              "node" : "target-data-node-id",
              "accept_data_loss" : true
            }
        }
    ]
}'

除了使用一次性数据进行开发之外，关闭副本通常是一个坏主意。

同样，我的记录数一度下降到 400m，但随后又随机回升至 900m。我不知道这意味着什么，任何见解将不胜感激。

发生这种情况是因为分片在集群中不可见。如果正在分配、重定位或恢复分片的所有副本，则可能会发生这种情况。这对应于 RED 集群状态。您可以通过确保至少有 1 个副本来缓解它（尽管理想情况下，您设置了足够数量的副本以在集群中丢失 N 个数据节点的情况下幸存）。这让 Elasticsearch 可以将一个分片作为主分片，同时移动其他分片。

如果您只有主节点而没有副本，那么如果主节点正在恢复或重新定位，则该分片中的数据将在集群中不可见。一旦分片再次处于活动状态，其中的文档就会变得可见。

推荐阅读