The index.routing.allocation.include._host
setting in Elasticsearch is used to control shard allocation based on host names. It allows you to specify which hosts are eligible for storing shards of a particular index.
- Default Value: Not set (no host restrictions)
- Possible Values: Comma-separated list of host names or IP addresses
- Recommendations: Use this setting when you need to ensure that shards are allocated to specific hosts, for example, to keep certain data on high-performance machines.
This setting is part of the shard allocation filtering mechanism in Elasticsearch. When set, it ensures that the index's shards are only allocated to the nodes running on the specified hosts.
Example
To set the index.routing.allocation.include._host
for an existing index:
PUT /my-index/_settings
{
"index.routing.allocation.include._host": "host1.example.com,host2.example.com"
}
This configuration will ensure that shards of my-index
are only allocated to nodes running on host1.example.com
or host2.example.com
.
Reasons for changing this setting might include:
- Ensuring critical data is stored on specific, high-performance machines
- Implementing data locality for improved query performance
- Complying with data residency requirements
The effect of this change is that Elasticsearch will move shards to comply with the new allocation rules, which may cause temporary increased I/O and network traffic.
Common Issues or Misuses
- Over-restricting shard allocation, leading to unbalanced cluster states
- Forgetting to update the setting when new hosts are added to the cluster
- Using IP addresses that may change, causing allocation issues
Do's and Don'ts
- Do use this setting in conjunction with other allocation settings for fine-grained control
- Do consider using this setting for data locality or compliance reasons
- Don't over-restrict allocation, which can lead to unbalanced clusters or allocation failures
- Don't forget to update this setting when adding or removing nodes from your cluster
- Do use hostnames rather than IP addresses when possible for better maintainability
Frequently Asked Questions
Q: Can I use wildcards in the host names?
A: Yes, you can use wildcards. For example, host*.example.com
would match all hosts with names starting with "host" in the "example.com" domain.
Q: What happens if none of the specified hosts are available?
A: If no nodes matching the specified hosts are available, the shards will remain unassigned until a matching node becomes available.
Q: How does this setting interact with other allocation settings?
A: This setting is combined with other allocation settings using AND logic. All conditions must be met for a shard to be allocated to a node.
Q: Can I use this setting to move shards from one host to another?
A: Yes, by changing the setting to include only the target host(s), you can trigger Elasticsearch to move shards to those hosts.
Q: Is there a performance impact when changing this setting?
A: Changing this setting can trigger shard relocations, which may temporarily increase I/O and network usage. Plan such changes during off-peak hours if possible.