Resiliency: Backport Recovery / Snapshot file identity improvements to 1.3 #7857
Conversation
This file contains 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
| @@ -445,7 +447,15 @@ public void snapshot(SnapshotIndexCommit snapshotIndexCommit) { | |||
| // } | |||
|
|
|||
| BlobStoreIndexShardSnapshot.FileInfo fileInfo = snapshots.findPhysicalIndexFile(fileName); | |||
|
|
|||
| try { | |||
| // in 1.4.0 we added additional hashes for .si / segments_N files | |||
There was a problem hiding this comment.
Should we update this comment to say 1.3.3? I suppose we should update master/1.x too, so we have accurate "history" in case we are debugging something.
s1monw
added a commit
to s1monw/elasticsearch
that referenced
this pull request
Sep 24, 2014
|
looks good, thank you simon! |
|
LGTM |
This commit changes the way how files are selected for retransmission on recovery / restore. Today this happens on a per-file basis where the rather weak checksum and the file length in bytes is compared to check if a file is identical. This is prone to fail in the case of a checksum collision which can happen under certain circumstances. The changes in this commit move the identity comparsion to a per-commit / per-segment level where files are only treated as identical iff all the other files in the commit / segment are the same. This "all or nothing" strategy is reducing the chance for a collision dramatically since we also use a strong hash to identify commits / segments based on the content of the ".si" / "segments.N" file. Closes elastic#7351
Due to additional safety added in elastic#7351 we compute now a strong hash for .si and segments_N files which are compared during snapshot / restore. Old snapshots don't have this hash which can cause unnecessary copying of large amount of data. This commit adds the ability to fetch this hash from the blob store if needed. Closes elastic#7434
The comparison and read code in the BlobStoreIndexShardRepository used the physicalName and Name in reverse order. This caused SnapshotBackwardsCompatibilityTest to fail.
We backported this feature to 1.3.3 as well so comments should be updated.
s1monw
added a commit
that referenced
this pull request
Sep 24, 2014
s1monw
added a commit
that referenced
this pull request
Sep 24, 2014
clintongormley
changed the title
mute
pushed a commit
to mute/elasticsearch
that referenced
this pull request
Jul 29, 2015
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
We saw lots of issues with hash collisions which have been fixed in 1.4 but back then it seemed like an improvement rather than a bugfix. I think in the meanwhile we should really declare it as a bugfix and port it into
1.3This backport PR includes fixes for #7434 & #7351 as well as related fixes.I ran BWC tests against 1.3.2 and 1.2.4 as well as the entire test suite multiple times but I think this need a deep review.