当前位置：首页 > news >正文

宁波网站建设优化东莞网络营销渠道

news 2025/7/11 1:29:54

宁波网站建设优化,东莞网络营销渠道,网站打不开dns修改,沈阳网站营销推广问题背景换节点我们线上有一套ES集群，三台机器，共运行了6个节点。一直在线上跑了几个月也一直没出什么问题。然而好巧不巧，就在昨天，集群中的3号节点磁盘出现故障，导致机器直接瘫痪。本来大家觉得问题不大&#xf…

问题背景

换节点

我们线上有一套ES集群，三台机器，共运行了6个节点。一直在线上跑了几个月也一直没出什么问题。然而好巧不巧，就在昨天，集群中的3号节点磁盘出现故障，导致机器直接瘫痪。本来大家觉得问题不大，ES不是有容灾吗，换个新节点上去不就能自动分配分片了。

unassigned

当我们信心满满换了个新节点上去之后，集群状态一直为red，我们发现一直存在180多个unassigned shards。

curl -XGET http://localhost:9200/_cluster/health{"cluster_name": "escluster","status": "red","timed_out": false,"number_of_nodes": 6,"number_of_data_nodes": 6,"active_primary_shards": 498,"active_shards": 767,"relocating_shards": 0,"initializing_shards": 0,"unassigned_shards": 185,"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": 80.5672268907563
}

curl -XGET http://localhost:9200/_cat/shards | grep UNASSIGNED

问题排查

分片恢复并发数❌

既然出现Unassigned shards，也就是说有一些分片未被分片。期初我们想当然的认为应该是节点新加入集群，分片还没有完成恢复。为了加速分片分配，我们调大了分片恢复并发数。

curl -XPUT http://localhost:9200/_cluster/settings -H 'Content-Type: application/json' -d'
{"persistent": {"cluster.routing.allocation.node_concurrent_recoveries": 10 }
}
'

然而并没有什么卵用，等了半天还是没什么变化。

allocation explain

随后我们使用allocation explain指令来查看分片的分配状态

curl -XGET http://localhost:9200/_cluster/allocation/explain?pretty

通过unassigned_info我们可以看到，NODE_LEFT，就是说节点无了。last_allocation_status说的更明确：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，大意就是集群节点上找不到能用的副本。

我们也很疑惑啊，为了让ES容灾，ES索引默认都有1个副本的呀，按照ES分片的策略，副本分片不会和主分片分发在同一台机器上，昨天宕机宕了1个节点，不应该主分配与副本分片都丢失吧。莫非…莫非这索引没副本？？？

抱着试一试的心态，我们查看了其中一个丢失的索引的信息

curl -XGET http://localhost:9200/XXX-2022.03.15/_settings
{"XXX-2022.03.15": {"settings": {"index": {"routing": {"allocation": {"require": {"box_type": "hot"}}},"number_of_shards": "1","provided_name": "XXX-2022.03.15","creation_date": "1647273614797","number_of_replicas": "0","uuid": "Dy7G3ZaESYqLB_aFk8M3Cg","version": {"created": "7080099"}}}}
}

不查不知道，一查吓一跳，这索引分片数为1，且没有副本…我副本呢？？？赶紧与研发确认了一下，由于机器磁盘比较小，为了节约存储，开发在写入索引时把就没留副本！！！

好家伙，我直接好家伙，合着我们还指望ES容灾呢，这还容个锤子灾。破案了，问题找到了，但数据也是找不回来了。

解决方案

数据是找不回来了，但集群也不能一直red啊，还有180多个unassigned的分片得处理呢。

reroute❌

通过在网上搜索相关的解决方案，得知可以通过重建所以路由是可以解决问题的。

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

但我们由于数据节点已经丢失了，所以会收到如下报错：

这意味着什么呢，就是说除非丢失的节点重新加入集群，否则数据将消失。

allocate_empty_primary

数据是没法恢复了，所以我们只能将分片进行清空处理了。

curl -H 'Content-Type: application/json' \-XPOST http://localhost:9200/_cluster/reroute?pretty -d '{"commands" : [ {"allocate_empty_primary" :{"index" : "XXX", "shard" : 0,"node" : "target-data-node-id","accept_data_loss" : true}}]
}'