Elasticsearch集群健康状态显示为yellow排查
最近在处理商品SKU通过ES和MySQL查询结果不匹配的时候，留意到在elasticsearch中cluster health是yellow,仔细看了一下，elasticsearch的索引状态和集群状态的不同传达着不同得意思。查阅了文档和一些文章，对ES的集群状态有了新的认识。无论集群是单节点还是有上百个数据节点，elasticsearch都提供了API接口来查看集群的健康状态，这样可以提醒我们处理集群中某处的问题
集群的相关状态
- green: 所有主要和副本碎片均已分配。您的集群可以100％运行。
- yellow: 所有主分片均已分配，但至少缺少一个副本。没有数据丢失，因此搜索结果仍将是完整的。但是，您的高可用性在一定程度上受到了损害。如果更多碎片消失，则可能会丢失数据。可以将其yellow视为应该立即进行调查的警告。
- red: 至少缺少一个主分片（及其所有副本）。这意味着您缺少数据：搜索将返回部分结果，而对该分片建立索引将返回异常。
分片和副本的概念及区别
当有大量的文档时，由于内存的限制、磁盘处理能力不足、无法足够快的响应客户端的请求等，一个节点可能不够。这种情况下，数据可以分为较小的分片。每个分片放到不同的服务器上。当查询的索引分布在多个分片上时，ES会把查询发送给每个相关的分片，并将结果组合在一起，而应用程序并不知道分片的存在。即：这个过程对用户来说是透明的。
为提高查询吞吐量或实现高可用性，可以使用分片副本。副本是一个分片的精确复制，每个分片可以有零个或多个副本。ES中可以有许多相同的分片，其中之一被选择更改索引操作，这种特殊的分片称为主分片。当主分片丢失时，如：该分片所在的数据不可用时，集群将副本提升为新的主分片。
- 分片与副本的区别在于：当分片设置为5，数据量为30G时，es会自动帮我们把数据均衡地分配到5个分片上，即每个分片大概有6G数据，当你查询数据时，ES会把查询发送给每个相关的分片，并将结果组合在一起。而副本，就是对分布在5个分片的数据进行复制。因为分片是把数据进行分割而已，数据依然只有一份，这样的目的是保障查询的高效性，副本则是多复制几份分片的数据，这样的目的是保障数据的高可靠性，防止数据丢失。
elasticsearch集群黄色的原因排查及解决方案
-
部署了单节点集群
由于只有一个节点，而elasticsearch采用默认配置（5分片，1副本），因此群集无法放置副本会处于黄色状态。
解决方案如下:
可以将副本计数降低到0或将第二个节点添加到群集，以便可以将主分片和副本分片安全地放在不同的节点上。这样做以后，如果您的节点崩溃，群集中的另一个节点将拥有该分片的副本。 -
elasticsearch分配分片错误
进一步可能的原因：已经为集群中的节点数过分分配了副本分片的数量，则分片将保持UNASSIGNED状态。其错误码为：ALLOCATION_FAILED。
解决方案如下：
reroute：重新路由命令允许手动更改群集中各个分片的分配。 -
磁盘使用过载
磁盘使用超过设定百分比85%。
cluster.routing.allocation.disk.watermark.low——控制磁盘使用的低水位线。 它默认为85％，这意味着Elasticsearch不会将分片分配给使用磁盘超过85％的节点。 它也可以设置为绝对字节值（如500mb），以防止Elasticsearch在小于指定的可用空间量时分配分片。
解决方案：
（1）查看磁盘空间是否超过85%。
（2）删除不必要的索引，以释放更多的空间 -
磁盘路径权限问题
磁盘路径权限问题。安全起见，默认Elasticsearch非root账户和启动。相关的Elasticsearch数据路径也是非root权限。
解决方案：
去数据存储路径排查权限，或者在data的最外层设置：chown -R elasticsearch:elasticsearch data
elasticsearch 健康状态API
- 集群状态查看
curl -XGET 'http://localhost:9200/_cluster/health?pretty=true' - 分片状态查看
curl -XGET 'http://localhost:9200/_cat/shards?v' - 查看unsigned 的原因
curl -XGET 'http://localhost:9200//_cluster/allocation/explain' - 查看集群中不同节点、不同索引的状态
curl -XGET 'http://localhost:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason'
