本文介绍了Elasticsearch集群中未分配shard的情况，特别是当replica shard未分配导致集群呈现Yellow状态时，分析了黄色状态的影响以及如何通过GET /_cat/shards API检查问题。如果shard长时间未分配，可能由于节点上的索引文件损坏，需要人工干预，如删除损坏文件。同时，建议监控集群健康状态，以便及时发现和解决问题。
Elasticsearch的主master节点管理shard在数据节点间的分配，如果有足够多的数据节点，它自动分配shard（primary和replica）到相应的数据节点上。但某些特殊的情况下，也会有未分配shard。如果未分配的是 replica shard，则整个集群处于Yellow状态。在你有足够的replica shard备份的情况下， yellow并不影响集群的整体可用性（但搜索性能可能会有下降），而且很多时候可以自动恢复，不需要任何人工干预，比如：某个数据节点的系统在打补丁或者系统维护时会被自动重新启动。
但如果shard长时间处于未分配状态，则需要特别注意了，往往需要人工干预。例如：节点上索引文件损坏。通过GET /_cat/shards API 查看哪个节点存在未分配的shard，在节点日志文件中会发现如下的内容。造成这种情况的原因可能有多种，直接删除损坏的文件既可以解决问题。
[2014-12-22 16:03:27,347][WARN ][index.engine.internal ] [ES-10-data] [ppub-v5][22] failed engine [corrupted preexisting index]
[2014-12-22 16:03
扫一扫
870
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
