原文转自我的博客
问题描述
ElasticSearch开箱即用，本身并没有太多需要配置、调整的参数，平时使用中最大的问题应该就是red状态的处理恢复了。现某用户使用的ES集群报health状态为red要求技术支持。我们首先看到用户提供的状态信息：
{
"cluster_name" : "real_cluster",
"status" : "red",
"timed_out" : false,
"number_of_nodes" : 101,
"number_of_data_nodes" : 98,
"active_primary_shards" : 12345,
"active_shards" : 23456,
"relocating_shards" : 0,
"initializing_shards" : 40,
"unassigned_shards" : 51,
"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": 99.704321
}
上述信息后台可以通过命令获取：
curl -X GET "localhost:9200/_cluster/health?pretty"
# 如果开启Xpack了，需要带上密码访问
curl -X GET -k -u username:passwd "https://localhost:9200/_cluster/health?pretty"
上述GET命令也可以直接粘贴在浏览器里获得结果。
问题定位
-
界面观察
已知信息是生产环境实际上的ES的数据节点（data node）理论上是99个，现在是98个，master节点是3个。
用户已经反馈从管理界面上观察ES所有实例服务状态全部正常，但集群health是
red，这里的差异在于管理页面是检查进程pid判断是否存活的，而ES集群内 部则需要心跳发现机制，因此Web页面显示ES状态ok，但health显示少一个ES节点，表明有一个ES的数据节点（这里称为Slave）失联了。
现在的首要任务就是找到99个es实例里谁在滥竽充数，假装活着！
-
后台日志
后台先去查看ES的master的
real_cluster.log，没有找到关于连接的异常信息，里面查不到ERROR。后台再去看个ES的slave的日志
real_cluster.log，直接翻到最后，发现有连接类的错误出现了。定位的关键内容摘要如下：
xxx-slave failed to connect to xxx2-slave7 ConnectTransportException xxx2-slave7 general node connection failure ……省略很长一串at ……这里的关键信息就是一个slave报告说连不上【xxx2-slave7】，这就找到了。
查看更多其他slave节点的日志，也都是报连不上【
xxx2-slave7】 综上，这个ES实例的名字知道了，顺藤摸瓜，服务器节点是xxx2，ES实例名是slave7，这种错误一般是集群压力大，心跳通信出问题，我们需要去重启这个ES实例。
问题处理
恢复失联的那个ES实例：上一步我们已经定位到了问题节点，需要通过管理页面重启。
页面显示重启该ES Slave成功（实际上没有成），过一会儿观察该实例并未在启动状态，ES仍是
red，node仍然少一个。-
再次启动该ES实例，显示成功不久后又挂掉了,属于后台进程启动不久后失败，此时去后台查该实例的日志发现有报错：
# 关键词 failed to bind service IOException: failed to find metadata for existing index xxx …… [locaton: xxx] -
该问题处理办法是删除实例对应的manifest文件。
这个文件的位置在该ES实例的数据存储目录下，如
/data/es/slave7/nodes/0/_state，其中nodes/0/_state这几个目录应该是不变的，前面的路径随配置。这个_state下面有
manifest-xxx.st文件，直接删除或者备份后删除该文件。 再次重启该ES实例，如果等一会还未加入ES集群，日志里显示该节点频繁add、remove，再次重启该实例。
观察health，好了ES的节点数完全恢复了（从98变回了99），集群状态很快从
red变成yellow了。-
重点观察,
initializing_shards和unassigned_shards一般逐渐减小，分片正在恢复中。"initializing_shards" : 40, "unassigned_shards" : 51, …… "active_shards_percent_as_number": 99.884321集群活跃分片百分比升高，等所有分片恢复完成，则集群会恢复
green。索引分片数据量很大时，恢复需要花费几个小时。
后续处理
-
如果
initializing_shards减小到0了，还有未分配的分片（unassigned_shards不是0），首先应查看未分配的原因，但一般情况可以先执行reroute命令：# 尤其在报错原因里提示分配失败是因为达到最大分配次数时，可使用这个命令。 POST /_cluster/reroute?retry_failed=true&pretty -
其他根据
explain的原因对症下药。# 这个命令用来查看分片不分配的原因： curl -XGET -k -u name:pass https:esip:9200/_cluster/allocation/explain?pretty # 输出的内容可能很多，可以保存到文件查看。
