以下的问题及方案探讨来自：微信交流及腾讯会议。

症状：集群重启无法启动，已启动了20个小时+，集群仍然无法完全恢复正常状态。

经交流反馈：之前，最长时间 8 小时启动集群。现在临近过年放假，直接无法启动。

Caused by: org.elasticsearch.action.UnavailableShardsException: [.monitoring-kibana-7-2023.01.17][0] primary shard is not active Timeout: [1m], request: [BulkShardRequest [[.monitoring-kibana-7-2023.01.17][0]] containing [2] requests] ... 11 more[2023-01-17T06:19:46,326][WARN ][o.e.x.m.e.l.LocalExporter] [datanodeprod5.synnex.org] unexpected error while indexing monitoring document

Something else entirely?

大前提：企业技术团队提出的方案都是基于 Setting 等的修改，但是当前集群一直处于主分片分配的状态，集群一直 red，很多操作是无法执行的。

我们采取一遍交流一遍排查问题，交流发现如下问题：

一句话概括描述问题所在：

基于如下五种情况，Elasticsearch 自动执行恢复（recovery）：

https://www.elastic.co/guide/en/elasticsearch/reference/current/cat-recovery.html

在集群尚可用的情况下，可以尝试使用以下操作：

GET _cat/recovery?v=true&h=i,s,t,ty,st,shost,thost,f,fp,b,bp&s=index:desc

用途：返回有关分片恢复的信息，包括正在进行的和已完成的。

注意：分片恢复完成后，恢复的分片可用于搜索和索引。

如下设置若生效，本质上是：

node_concurrent_incoming_recoveries和 node_concurrent_outgoing_recoveries同时生效。

incoming_recoverie可以简单理解为副本分片的恢复，outgoing_recoveries可以简单理解为主分片的恢复。

PUT _cluster/settings{"transient": {"cluster.routing.allocation.node_concurrent_recoveries": 3}}

默认值是2，理论上调大会增大并发。

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html

当节点出于任何原因（人为原因或系统异常）离开集群时，主节点会做出以下反应（如下称为步骤 X 是方便后续的解读）：

以上操作的好处是：避免集群数据丢失，确保集群高可用。

但可能带来的副作用也非常明显：其一，会给集群带来额外的负载（分片分配非常耗费系统资源）；其二，若离开集群的节点很快返回，上述机制的必要性就有待商榷。

此时，延迟分片分配就显得非常必要，设置如下：

PUT _all/_settings{  "settings": {    "index.unassigned.node_left.delayed_timeout": "6m"  }}

当节点离开集群并确认几分钟（自己设定）可以快速上线的情况下，离开的过程中只触发步骤1的将离开节点上的对应的副本分片提升为主分片。此时集群至少不是red 状态，而是yellow状态。步骤2、步骤3不会发生，此时集群是可用的，待设定的几分钟内下线集群确保重新上线后，分片再重新转为副本分片，此时集群恢复绿色状态。

这个过程有效避免了步骤2、步骤3的分片分配，整体上以最短的时间确保了集群的高可用性。

https://www.elastic.co/guide/en/elasticsearch/reference/current/delayed-allocation.html

• 如下的验证，仅在单节点集群验证 ok，多节点原理一致。

• 涉及文件的操作，是无法之法，万不得已，不要直接操作文件。