Refactor state format to use incremental state IDs#10316
Merged
s1monw merged 1 commit intoelastic:masterfrom Mar 31, 2015
Merged
Refactor state format to use incremental state IDs#10316s1monw merged 1 commit intoelastic:masterfrom
s1monw merged 1 commit intoelastic:masterfrom
Conversation
Contributor
There was a problem hiding this comment.
can we use Pattern.qoute for the prefix? just being paranoid..
Contributor
Author
|
@bleskes pushed a new commit |
Contributor
|
I left one comment regarding the use of versions in determining the counter. Another thing I was wondering about is how we deal with the scenario 1.5.0 can live us in - a higher id legacy file, with a lower id and non legacy file. |
Contributor
Author
we don't deal with that at all. IMO this requires user interaction - no way to resolve it automatically and I don't think we should unless it's evident that there is a real problem here that happens regularly. |
Contributor
Fair enough. Let's wait and see. |
Contributor
Author
|
@bleskes can you take another look? |
Contributor
There was a problem hiding this comment.
rename this to StateIdAndLegacyPredicate?
Contributor
|
LGTM |
Today there is a chance that the state version for shard, index or cluster state goes backwards or is reset on a full restart etc. depending on several factors not related to the state. To prevent any collisions with already existing state files and to maintain write-once properties this change introductes an incremental state ID instead of using the plain state version. This also fixes a bug when the previous legacy state had a greater version than the current state which causes an exception on node startup or if left-over files are present. Closes elastic#10316
s1monw
force-pushed
the
refactor_state_format
branch
from
89bba2e to
78d86bc
Compare
s1monw
added a commit
to s1monw/elasticsearch
that referenced
this pull request
Apr 1, 2015
Today there is a chance that the state version for shard, index or cluster state goes backwards or is reset on a full restart etc. depending on several factors not related to the state. To prevent any collisions with already existing state files and to maintain write-once properties this change introductes an incremental state ID instead of using the plain state version. This also fixes a bug when the previous legacy state had a greater version than the current state which causes an exception on node startup or if left-over files are present. Closes elastic#10316
s1monw
added a commit
to s1monw/elasticsearch
that referenced
this pull request
Apr 1, 2015
Today there is a chance that the state version for shard, index or cluster state goes backwards or is reset on a full restart etc. depending on several factors not related to the state. To prevent any collisions with already existing state files and to maintain write-once properties this change introductes an incremental state ID instead of using the plain state version. This also fixes a bug when the previous legacy state had a greater version than the current state which causes an exception on node startup or if left-over files are present. Closes elastic#10316
clintongormley
added
resiliency
:Distributed/Recovery
clintongormley
changed the title
mute
pushed a commit
to mute/elasticsearch
that referenced
this pull request
Jul 29, 2015
Today there is a chance that the state version for shard, index or cluster state goes backwards or is reset on a full restart etc. depending on several factors not related to the state. To prevent any collisions with already existing state files and to maintain write-once properties this change introductes an incremental state ID instead of using the plain state version. This also fixes a bug when the previous legacy state had a greater version than the current state which causes an exception on node startup or if left-over files are present. Closes elastic#10316
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Today there is a chance that the state version for shard, index or cluster
state goes backwards or is reset on a full restart etc. depending on
several factors not related to the state. To prevent any collisions
with already existing state files and to maintain write-once properties
this change introductes an incremental state ID instead of using the plain
state version. This also fixes a bug when the previous legacy state had a
greater version than the current state which causes an exception on node
startup or if left-over files are present.