-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
1.x to 5.0 upgrade #19843
Comments
we are currently evaluating options here since there might be a chance of a smooth upgrade path for the field names problem. Yet, there is still a change that it won't happen but I am positive along those lines. Stay tuned it might take a couple of days. |
To be sure we are on the same page, there will need to be a massive reindex anyway. The dot-in-field-names support in 2.x would only help do the reindex one index at a time rather than having to maintain two clusters side by side, and has the drawback that data will need to be reindexed again in order to upgrade to 6.0 (since it will only support 5.0+ indices) or enjoy the 5.0 index format improvements such as the faster/smaller numerics. So going through 2.x would actually require more cpu and I/O in total since data will have to be reindexed twice, it only has the benefit to not require to set up two clusters in parallel. |
Also note that to migrate from 1.x to 5.x does not require double the nodes. You can start with a small 5.x cluster and start moving indices, and move nodes across to the new cluster as needed. |
FYI - #19937 will allow to use dots in fieldnames in 2.4. All indices that don't have field name conflicts that are created on >= 2.4 can then be upgraded to 5.x without reindexing. |
@seang-es do you think we can close this with the solution in #19937 give this being your description:
|
Closing as there doesn't seem to be any objection to the suggestion of closing above. |
As far as I know, the current plan for upgrading from 1.x to 5.0 is to set up a parallel cluster and migrate from the original 1.x cluster to the 5.0 cluster using the remote reindexing feature of the Reindex API. That's fine if the user has enough hardware available to set up two parallel clusters and move things over, but we do have users deployed that do not have those resources. How can we handle an in-place upgrade from 1.x to 5.0?
This is an especially big problem with the reintroduction of dots in field names in 5.0, as users will not want to rename all their fields to get rid of dots for a 2.x upgrade, only to immediately upgrade to 5.0 where these fields are legal again. What are our options here?
The text was updated successfully, but these errors were encountered: