Node Concurrent Recoveries Low
The node concurrent recoveries setting is below the recommended value. Shard recovery after node loss or corruption might be unnecessarily slow.
For a complete list of insights, refer to AutoOps insights.
| Field | Value |
|---|---|
| Component | Elasticsearch |
| Severity | Medium |
| Scope | Cluster |
| Domains | performance, configuration, recovery |
You can customize these settings to adjust when AutoOps detects this event and presents the insight. Refer to AutoOps event settings for details.
The default customization settings are:
| Setting | Type | Default |
|---|---|---|
| Maximum node concurrent recoveries | Integer | 2 |
The following is an example of what you might see when this insight is triggered. Real insights use live data and links from your deployment or cluster.
The current concurrent recoveries setting is set to: 12. The recommended setting is 12.
AutoOps shows different recommendations depending on how their conditions match your deployment or cluster.
Increase concurrent recoveries limit
Condition: Always shown for this insight.
cluster.routing.allocation.node_concurrent_recoveries limits how many shards recover to one node at once. Raise it with the action below to speed recovery; lower values reduce overload risk but take longer.
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.node_concurrent_recoveries": 12
}
}
Requires the manage cluster privilege. Requires Elasticsearch 8.0.0 or later. This action changes cluster or index configuration.
Impact: Primary and replica shards might not get restored following loss or corruption of shards, which could cause data loss. Following the loss of a node or in the case of data corruption, the master will try to recover shards across the network. The number of recoveries that can take place at any one time is limited by the node_concurrent_recoveries setting. If this is set below the default value then it could unnecessarily limit the speed at which shards are recovered.