Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A setting to auto expand the number of replicas of an index (based on data nodes) #623

Closed
kimchy opened this issue Jan 12, 2011 · 3 comments

Comments

@kimchy
Copy link
Member

kimchy commented Jan 12, 2011

Allow to set index.auto_expand_replicas to have the cluster automatically expand the number of an replicas an index has based on the data nodes there are in the cluster.

For example, setting: index.auto_expand_replicas to 0-all will have the number of replicas always expand to the full number of data nodes in the cluster.

Setting it to 1-all will do the same as above, just with a lower bounding value of keeping 1 replica settings always, even if there is just one node.

Setting it to 2-4 will bound the number of replicas between 2 and 4.

@kimchy
Copy link
Member Author

kimchy commented Jan 12, 2011

A setting to auto expand the number of replicas of an index (based on data nodes), closed by 85b6a98.

@clintongormley
Copy link

Any chance that we can set auto_expand_replicas using the update_settings API?

@kimchy
Copy link
Member Author

kimchy commented Mar 21, 2011

Sure, I will create a different issue for this.

tallpsmith pushed a commit to tallpsmith/elasticsearch that referenced this issue May 5, 2011
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this issue Oct 2, 2023
I've run each of these tracks in `--test-mode` with disk usage telemetry
enabled and it worked. These aren't any of the tracks known to be broken
under the disk usage telemetry. So it should be safe!
emilykmarx pushed a commit to emilykmarx/elasticsearch that referenced this issue Dec 26, 2023
These specs don't make sense because x-pack master isn't publicly available. We should be well covered by the tests against the current released branch.

Alternatively we could use a different testing approach with a different HTTPS/Auth provider in the future

Fixes elastic#623
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants