这篇文章给大家介绍Elasticsearch 集群健康值红色终极解决方案是怎样的，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
Elasticsearch当清理缓存（ echo 3 > /proc/sys/vm/drop_caches ）的时候，出现
如下集群健康值：red，红色预警状态，同时部分分片都成为灰色。 
查看Elasticsearch启动日志会发现如下：
集群服务超时连接的情况。
bserver: timeout notification from cluster service. timeout setting [1m], time since start [1m]
该问题排查耗时很长，问题已经解决。
特将问题排查及解决方案详尽的整理出来。
head插件会以不同的颜色显示。
1）、绿色——最健康的状态，代表所有的主分片和副本分片都可用；
2）、黄色——所有的主分片可用，但是部分副本分片不可用；
3）、红色——部分主分片不可用。（此时执行查询部分数据仍然可以查到，遇到这种情况，还是赶快解决比较好。）
参考官网：http://t.cn/RltLEpN（部分中文集群健康状态博文资料翻译的不够精确，以官网为准）
如果集群状态为红色， Head插件显示：集群健康值red 。则说明：至少一个主分片分配失败。
这将导致一些数据以及索引的某些部分不再可用。
尽管如此， ElasticSearch还是允许我们执行查询，至于是通知用户查询结果可能不完整还是挂起查询，则由应用构建者来决定。
一句话解释：未分配的分片。
启动ES的时候，通过Head插件不停刷新，你会发现集群分片会呈现紫色、灰色、最终绿色的状态。
如果不能分配分片，例如，您已经为集群中的节点数过分分配了副本分片的数量，则分片将保持UNASSIGNED状态。
其错误码为：ALLOCATION_FAILED。
你可以通过如下指令，查看集群中不同节点、不同索引的状态。
GET _cat/shards?h=index,shard,prirep,state,unassigned.reason
head插件查看会：Elasticsearch启动N长时候后，某一个或几个分片仍持续为灰色。
方案一：极端情况——这个分片数据已经不可用，直接删除该分片。
ES中没有直接删除分片的接口，除非整个节点数据已不再使用，删除节点。
curl -XDELETE ‘localhost:9200/index_name/’
方案二：集群中节点数量>=集群中所有索引的最大副本数量 +１。
N> = R + 1
其中：
N——集群中节点的数目；
R——集群中所有索引的最大副本数目。
知识点：当节点加入和离开集群时，主节点会自动重新分配分片，以确保分片的多个副本不会分配给同一个节点。换句话说，主节点不会将主分片分配给与其副本相同的节点，也不会将同一分片的两个副本分配给同一个节点。
如果没有足够的节点相应地分配分片，则分片可能会处于未分配状态。
由于我的集群就一个节点，即Ｎ＝１；所以Ｒ＝０，才能满足公式。
问题就转嫁为：
１）添加节点处理，即Ｎ增大；
２）删除副本分片，即R置为0。
R置为0的方式，可以通过如下命令行实现：
root@tyg:/# curl -XPUT "http://localhost:9200/_settings" -d' { "number_of_replicas" : 0 } '{"acknowledged":true}方案三：allocate重新分配分片。
如果方案二仍然未解决，可以考虑重新分配分片。
可能的原因：
1）节点在重新启动时可能遇到问题。正常情况下，当一个节点恢复与群集的连接时，它会将有关其分片的信息转发给主节点，然后主节点将这分片从“未分配”转换为“已分配/已启动”。
2）当由于某种原因（例如节点的存储已被损坏）导致该进程失败时，分片可能保持未分配状态。
在这种情况下，您必须决定如何继续：尝试让原始节点恢复并重新加入集群（并且不要强制分配主分片）；
或者强制使用Reroute API分配分片并重新索引缺少的数据原始数据源或备份。
如果您决定分配未分配的主分片，请确保将“allow_primary”：“true”标志添加到请求中。
ES5.X使用脚本如下：
ES2.X及早期版本，将 allocate_replica改为 allocate，其他不变。
脚本解读：
步骤1：定位 UNASSIGNED 的节点和分片
curl -s 'localhost:9200/_cat/shards' | fgrep UNASSIGNED
步骤2：通过 allocate_replica 将 UNASSIGNED的分片重新分配。
1）路由
原理很简单，把每个用户的数据都索引到一个独立分片中，在查询时只查询那个用户的分片。这时就需要使用路由。
使用路由优势：路由是优化集群的一个很强大的机制。
它能让我们根据应用程序的逻辑来部署文档, 从而可以用更少的资源构建更快速的查询。
2）在索引过程中使用路由
我们可以通过路由来控制 ElasticSearch 将文档发送到哪个分片。
路由参数值无关紧要，可以取任何值。重要的是在将不同文档放到同一个分片上时, 需要使用相同的值。
3）指定路由查询
路由允许用户构建更有效率的查询，当我们只需要从索引的一个特定子集中获取数据时, 为什么非要把查询发送到所有的节点呢?
指定路由查询举例:
curl -XGET 'localhost:9200/documents/_search?pretty&q=*:*&routing=A'
4）集群再路由reroute
reroute命令允许显式地执行包含特定命令的集群重新路由分配。
例如，分片可以从一个节点移动到另一个节点，可以取消分配，或者可以在特定节点上显式分配未分配的分片。
5）allocate分配原理
分配unassigned的分片到一个节点。
将未分配的分片分配给节点。接受索引和分片的索引名称和分片号，以及将分片分配给它的节点。。
它还接受allow_primary标志来明确指定允许显式分配主分片（可能导致数据丢失）。
1）该问题的排查累计超过6个小时，最终找到解决方案。之前几近没有思路，想放弃，但咬牙最终解决。
2) 切记，第一手资料很重要！
Elasticsearch出现问题，最高效的解决方案是第一手资料ES英文官网文档，其次是ES英文论坛、ES github issues，再次是stackoverflow等英文论坛、博客。最后才是：Elasticsearch中文社区、其他相关中文技术博客等。
关于Elasticsearch 集群健康值红色终极解决方案是怎样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
