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

Core: Upgrade API should write minimum compatible version that the index was upgrade to #11095

Closed
imotov opened this issue May 11, 2015 · 8 comments · Fixed by #11333
Closed
Assignees
Labels

Comments

@imotov
Copy link
Contributor

imotov commented May 11, 2015

In #11072 we are adding a check that will prevent opening of old indices. However, this check doesn't take into consideration the fact that indices can be made compatible with the current version through upgrade API. In order to make compatibility check aware of the upgrade, the upgrade API should write a new setting index.version.minimum_compatible that will indicate the minimum compatible version of elasticsearch/lucene this index is compatible with.

@rjernst
Copy link
Member

rjernst commented May 11, 2015

I don't think this should just be on upgrade? It should be all merges really, since it may be true older segments are simply merged away naturally, without needing to call upgrade. I'm not sure how feasible that is though...

@rjernst
Copy link
Member

rjernst commented May 11, 2015

Perhaps on every flush, since that is the "durable" part of an upgrade?

@clintongormley
Copy link

Doing a cluster state update on every flush seems excessive.

The only time this setting is used is when we move to a new major version, while having indices from 2 major versions before.

If all your ancient segments have been merged away, then calling the upgrade API with only_ancient_segments would only update this setting.

@s1monw what do you think of the naming for this setting? And what should go in it? ES version or Lucene version?

@rjernst
Copy link
Member

rjernst commented May 15, 2015

Doing a cluster state update on every flush seems excessive.

It would only need to do the update if the min version changed?

@clintongormley
Copy link

true :)

@s1monw
Copy link
Contributor

s1monw commented May 19, 2015

Perhaps on every flush, since that is the "durable" part of an upgrade?

I think we can actually do that since we only need to change the index settings / metadata iff we have a change in the min version. I think this should be rather rare?

@imotov imotov self-assigned this May 19, 2015
@imotov
Copy link
Contributor Author

imotov commented May 20, 2015

Adding a setting during as part of Upgrade API is relatively simple and straightforward change. Updating setting on each flush/merge will require 1) plug a segment version check into merge process and checking the version of all segments at the end of merge, 2) sending the minimum segment version to some centralized location, probably a service running on master, 3) the said service will need to keep track of minimum segment version across all shards, which is challenge in itself because replicas don't really have identities. 4) as soon as the minimum version across all shards changes this service will update index.version.minimum_compatible setting. Can anyone see a simpler solution?

@clintongormley
Copy link

Honestly, this is a one-time thing, when you do a major upgrade. I'd go the simple route and just set the setting when called by the upgrade API

imotov added a commit to imotov/elasticsearch that referenced this issue May 25, 2015
…ble version that the index was upgraded to

In elastic#11072 we are adding a check that will prevent opening of old indices. However, this check doesn't take into consideration the fact that indices can be made compatible with the current version through upgrade API. In order to make compatibility check aware of the upgrade, the upgrade API should write a new setting `index.version.minimum_compatible` that will indicate the minimum compatible version of lucene this index is compatible with and `index.version.upgraded` that will indicate the version of elasticsearch that performed the upgrade.

Closes elastic#11095
imotov added a commit to imotov/elasticsearch that referenced this issue May 28, 2015
…ble version that the index was upgraded to

In elastic#11072 we are adding a check that will prevent opening of old indices. However, this check doesn't take into consideration the fact that indices can be made compatible with the current version through upgrade API. In order to make compatibility check aware of the upgrade, the upgrade API should write a new setting `index.version.minimum_compatible` that will indicate the minimum compatible version of lucene this index is compatible with and `index.version.upgraded` that will indicate the version of elasticsearch that performed the upgrade.

Closes elastic#11095
imotov added a commit that referenced this issue May 28, 2015
…ble version that the index was upgraded to

In #11072 we are adding a check that will prevent opening of old indices. However, this check doesn't take into consideration the fact that indices can be made compatible with the current version through upgrade API. In order to make compatibility check aware of the upgrade, the upgrade API should write a new setting `index.version.minimum_compatible` that will indicate the minimum compatible version of lucene this index is compatible with and `index.version.upgraded` that will indicate the version of elasticsearch that performed the upgrade.

Closes #11095
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
4 participants