The cluster.routing.allocation.include setting in Elasticsearch is used to control shard allocation based on custom node attributes. It allows you to specify which nodes are eligible for shard allocation based on defined criteria.
- Default value: Empty (no restrictions)
- Possible values: Comma-separated list of key-value pairs
- Recommendations: Use sparingly and in conjunction with other allocation settings for balanced cluster management
This setting works by including nodes that match the specified attributes for shard allocation. It can be applied at the cluster, index, or shard level. When set, Elasticsearch will only allocate shards to nodes that have matching attribute values.
Example
To set the cluster.routing.allocation.include at the cluster level:
PUT _cluster/settings
{
"persistent": {
"cluster.routing.allocation.include.rack": "rack1,rack2"
}
}
This example restricts shard allocation to nodes with the rack attribute set to either rack1 or rack2. You might use this to ensure data is distributed across specific racks for improved fault tolerance.
Common Issues and Misuses
- Over-restricting allocation, leading to unbalanced shard distribution
- Conflicting with other allocation settings, causing unexpected behavior
- Forgetting to update the setting when adding new nodes with different attributes
Do's and Don'ts
Do's:
- Use in combination with
excludeandrequiresettings for fine-grained control - Regularly review and update as your cluster grows or changes
- Document your allocation strategy for easier maintenance
Don'ts:
- Don't rely solely on this setting for critical allocation decisions
- Avoid overly complex allocation rules that may be hard to manage
- Don't forget to consider the impact on cluster balance and performance
Frequently Asked Questions
Q: How does cluster.routing.allocation.include differ from cluster.routing.allocation.require?
A: While include allows allocation if any of the specified values match, require demands that all specified values must match for allocation to occur.
Q: Can I use wildcards in the attribute values?
A: Yes, you can use wildcards. For example, rack_* would match any rack attribute starting with "rack_".
Q: How does this setting interact with other allocation settings?
A: This setting is applied in conjunction with other allocation settings. The most restrictive combination of settings will determine the final allocation behavior.
Q: Can I set this at the index level instead of the cluster level?
A: Yes, you can apply this setting at the index level using the index settings API, which allows for more granular control over specific indices.
Q: What happens if no nodes match the include criteria?
A: If no nodes match the criteria, shards will remain unallocated until either matching nodes become available or the setting is adjusted.
