-
Notifications
You must be signed in to change notification settings - Fork 635
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
Cannot use copy_settings=true for shrink action #1347
Comments
Is there a solution for folks using an ES version less than 6.4? Right now running on a cluster version 6.3 the In some cases:
If you clean up the cluster and get it back to green, and try the |
Can anyone shed any light on how to use the copy_settings: True setting? I am running elasticsearch-curator-5.7.6-1.x86_64. Where should it be placed? Documentation on this option seems limited.
|
The setting has never been added, so, you can't use it yet. |
For usage questions and help
Please create a topic at https://discuss.elastic.co/c/elasticsearch
Perhaps a topic there already has an answer for you!
To submit a bug or report an issue
When using a shrink action, there is no option to pass a copy_settings=true parameter to elasticsearch. This prevents metricbeat indexes from being shrunk using curator since the index.mapping.total_fields.limit setting can not be copied over. The new index fails to start due to the number of fields being higher than the default limit of 1000.
Expected Behavior
The shrink API copy_settings parameter should be an option to set.
Actual Behavior
The new index fails to start due to the number of fields being higher than the default limit of 1000.
Steps to Reproduce the Problem
Create a metricbeat index with >2 shards.
Use curator to shrink index.
Specifications
Proposed Change
The copy_settings parameter will default to true starting in ES 7, but still needs to be set on ES 6.4+. Add a new option to set copy_settings to true and match default behavior and deprecation of copy_settings parameter of elasticsearch: elastic/elasticsearch#28347
The text was updated successfully, but these errors were encountered: