ES集群red状态排查与恢复

原文转自我的博客

问题描述

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命令也可以直接粘贴在浏览器里获得结果。

问题定位

1. 界面观察

   已知信息是生产环境实际上的ES的数据节点（data node）理论上是99个，现在是98个，master节点是3个。

   用户已经反馈从管理界面上观察ES所有实例服务状态全部正常，但集群health是red，这里的差异在于管理页面是检查进程pid判断是否存活的，而ES集群内 部则需要心跳发现机制，因此Web页面显示ES状态ok，但health显示少一个ES节点，表明有一个ES的数据节点（这里称为Slave）失联了。

现在的首要任务就是找到99个es实例里谁在滥竽充数，假装活着！

2. 后台日志

   后台先去查看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】

3. 综上，这个ES实例的名字知道了，顺藤摸瓜，服务器节点是xxx2，ES实例名是slave7，这种错误一般是集群压力大，心跳通信出问题，我们需要去重启这个ES实例。

问题处理

1. 恢复失联的那个ES实例：上一步我们已经定位到了问题节点，需要通过管理页面重启。

2. 页面显示重启该ES Slave成功（实际上没有成），过一会儿观察该实例并未在启动状态，ES仍是red，node仍然少一个。

3. 再次启动该ES实例，显示成功不久后又挂掉了,属于后台进程启动不久后失败，此时去后台查该实例的日志发现有报错：

   # 关键词
   failed to bind service
   IOException: failed to find metadata for existing index xxx …… [locaton: xxx]
   

4. 该问题处理办法是删除实例对应的manifest文件。

   这个文件的位置在该ES实例的数据存储目录下，如/data/es/slave7/nodes/0/_state，其中nodes/0/_state这几个目录应该是不变的，前面的路径随配置。

   这个_state下面有manifest-xxx.st文件，直接删除或者备份后删除该文件。

5. 再次重启该ES实例，如果等一会还未加入ES集群，日志里显示该节点频繁add、remove，再次重启该实例。

6. 观察health，好了ES的节点数完全恢复了（从98变回了99），集群状态很快从red变成yellow了。

7. 重点观察,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
  # 输出的内容可能很多，可以保存到文件查看。