ES集群red状态排查与恢复
ES集群red状态排查与恢复
问题描述
ElasticSearch开箱即用，本身并没有太多需要配置、调整的参数，平时使用中最大的问题应该就是red状态的处理恢复了。现某用户使用的ES集群报health状态为red要求技术支持。我们首先看到用户提供的状态信息：
json
{
"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，直接翻到最后，发现有连接类的错误出现了。
关键内容摘要如下：
shell
xxx-slave failed to connect to xxx2-slave7
ConnectTransportException xxx2-slave7 general node connection failure
……省略很长一串at
……
这里的关键信息就是一个slave报告说连不上【xxx2-slave7】，这就找到了。
查看更多其他slave节点的日志，也都是报连不上xxx2-slave7
- 综上，这个ES实例的名字知道了，顺藤摸瓜，节点是xxx2，实例编号是slave7，这种错误一般是集群压力大，心跳通信出问题，我们需要去重启这个ES实例。
问题处理
-
恢复失联的那个ES实例：上一步我们已经定位到了问题节点，需要通过管理页面重启。
-
页面显示重启该ES Slave成功（实际上没有成），过一会儿观察该实例并未在启动状态，ES仍是red，node仍然少一个。
-
再次启动该ES实例，显示成功不久后又挂掉了,属于后台进程启动不久后失败，此时去后台查该实例的日志发现有报错：
shell
# 关键词
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一般逐渐减小，分片正在恢复中。
shell
"initializing_shards" : 40,
"unassigned_shards" : 51,
……
"active_shards_percent_as_number": 99.884321
集群活跃分片百分比升高，等所有分片恢复完成，则集群会恢复green。
索引分片数据量很大时，恢复需要花费几个小时。
后续处理
- 如果
initializing_shards减小到0了，还有未分配的分片（unassigned_shards不是0），首先应查看未分配的原因，但一般情况可以先执行reroute命令：
shell
# 尤其在报错原因里提示分配失败是因为达到最大分配次数时，可使用这个命令。
POST /_cluster/reroute?retry_failed=true&pretty
- 其他根据
explain的原因对症下药。
shell
# 这个命令用来查看分片不分配的原因：
curl -XGET -k -u name:pass https:esip:9200/_cluster/allocation/explain?pretty
# 输出的内容可能很多，可以保存到文件查看。