Improve recovery / snapshot restoring file identity handling #7351
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
|
The diffing logic here etc looks great to me. |
| if (file.metadata.hash() != null && file.metadata().hash().length > 0) { | ||
| BytesRef hash = file.metadata.hash(); | ||
| // TODO - not sure if this is the right way to do this - can't we pass the bytes ref directly? | ||
| builder.field(Fields.META_HASH, Base64.encodeBytes(hash.bytes, hash.offset, hash.length)); |
There was a problem hiding this comment.
I think we should use field(String name, byte[] value, int offset, int length) or field(String name, BytesReference value) here and then use XContentParser#binaryValue to read this value back?
|
I left a couple of minor comments. Otherwise, looks good to me. |
|
@imotov I pushed a new commit including a test for the |
s1monw
force-pushed
the
fix_checksums
branch
2 times, most recently
from
5d48020
to
60b280c
Compare
|
LGTM |
|
I think we have a small regression here for snapshot and restore since we don't have the hash for the segments in the already existing snapshot. I think we can read the hashes for those where we calculated them from the snapshot on the fly if necessary. I will open a followup for this as I already discussed this with @imotov |
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
s1monw
added a commit
that referenced
this pull request
Aug 21, 2014
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 #7351
s1monw
added a commit
to s1monw/elasticsearch
that referenced
this pull request
Aug 26, 2014
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
s1monw
added a commit
that referenced
this pull request
Aug 26, 2014
Due to additional safety added in #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 #7434
s1monw
added a commit
that referenced
this pull request
Sep 8, 2014
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 #7351
s1monw
added a commit
that referenced
this pull request
Sep 8, 2014
Due to additional safety added in #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 #7434
clintongormley
changed the title
s1monw
added a commit
to s1monw/elasticsearch
that referenced
this pull request
Sep 24, 2014
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
s1monw
added a commit
to s1monw/elasticsearch
that referenced
this pull request
Sep 24, 2014
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
clintongormley
added
the
:Distributed/Snapshot/Restore
clintongormley
changed the title
mute
pushed a commit
to mute/elasticsearch
that referenced
this pull request
Jul 29, 2015
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
mute
pushed a commit
to mute/elasticsearch
that referenced
this pull request
Jul 29, 2015
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
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.
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 comparison 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 nothingstrategy is reducing the chance fora collision dramatically since we also use a strong hash to identify commits / segments
based on the content of the
.si/segments.Nfile.