Fix Bug With RepositoryData Caching#57785
Merged
original-brownbear merged 3 commits intoelastic:masterfrom Jun 8, 2020
original-brownbear:fix-broken-repo-data-cache
Merged
Fix Bug With RepositoryData Caching#57785original-brownbear merged 3 commits intoelastic:masterfrom original-brownbear:fix-broken-repo-data-cache
original-brownbear merged 3 commits intoelastic:masterfrom
original-brownbear:fix-broken-repo-data-cache
Conversation
This fixes a really subtle bug with caching `RepositoryData` that can corrupt a repository. We were caching `RepositoryData` serialized in the newest metadata format. This lead to a confusing situation where numeric shard generations would be cached in `ShardGenerations` that were not written to the repository because the repository or cluster did not yet support `ShardGenerations`. In the case where shard generations are not actually supported yet, these cached numeric generations are not safe and there's multiple scenarios where they would be incorrect, leading to the repository trying to read shard level metadata from index-N that don't exist. This commit makes it so that cached metadata is always in the same format as the metadata in the repository.
Collaborator
|
Pinging @elastic/es-distributed (:Distributed/Snapshot/Restore) |
Contributor
Author
|
The workaround to this bug would be to set the repository setting |
| * @param version version of the repository metadata that was cached | ||
| */ | ||
| private void cacheRepositoryData(RepositoryData updated) { | ||
| private void cacheRepositoryData(RepositoryData updated, Version version) { |
Contributor
Author
There was a problem hiding this comment.
There is an obvious and much cleaner fix here by simply caching the compressed form of the already serialized RepositoryData when writing/reading instead of re-serializing that would also improve efficiency. I just went with this approach now to have the smallest possible fix for a safe back-port.
ywelsch
reviewed
Jun 8, 2020
Contributor
ywelsch
left a comment
There was a problem hiding this comment.
Is there some test you could add that ensures we don't have regressions on this?
Contributor
Author
@ywelsch yes I think I have an idea on how to do that => on it |
Contributor
Author
Closed
2 tasks
Contributor
Author
|
Thanks Yannick! |
This was referenced Jun 8, 2020
original-brownbear
added a commit
that referenced
this pull request
Jun 8, 2020
* Fix Bug With RepositoryData Caching This fixes a really subtle bug with caching `RepositoryData` that can corrupt a repository. We were caching `RepositoryData` serialized in the newest metadata format. This lead to a confusing situation where numeric shard generations would be cached in `ShardGenerations` that were not written to the repository because the repository or cluster did not yet support `ShardGenerations`. In the case where shard generations are not actually supported yet, these cached numeric generations are not safe and there's multiple scenarios where they would be incorrect, leading to the repository trying to read shard level metadata from index-N that don't exist. This commit makes it so that cached metadata is always in the same format as the metadata in the repository. Relates #57798
original-brownbear
added a commit
that referenced
this pull request
Jun 8, 2020
* Fix Bug With RepositoryData Caching This fixes a really subtle bug with caching `RepositoryData` that can corrupt a repository. We were caching `RepositoryData` serialized in the newest metadata format. This lead to a confusing situation where numeric shard generations would be cached in `ShardGenerations` that were not written to the repository because the repository or cluster did not yet support `ShardGenerations`. In the case where shard generations are not actually supported yet, these cached numeric generations are not safe and there's multiple scenarios where they would be incorrect, leading to the repository trying to read shard level metadata from index-N that don't exist. This commit makes it so that cached metadata is always in the same format as the metadata in the repository. Relates #57798
original-brownbear
added a commit
that referenced
this pull request
Jun 8, 2020
This fixes a really subtle bug with caching `RepositoryData` that can corrupt a repository. We were caching `RepositoryData` serialized in the newest metadata format. This lead to a confusing situation where numeric shard generations would be cached in `ShardGenerations` that were not written to the repository because the repository or cluster did not yet support `ShardGenerations`. In the case where shard generations are not actually supported yet, these cached numeric generations are not safe and there's multiple scenarios where they would be incorrect, leading to the repository trying to read shard level metadata from index-N that don't exist. This commit makes it so that cached metadata is always in the same format as the metadata in the repository. Relates #57798
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
4 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.
This fixes a really subtle bug with caching
RepositoryData(introduced in #52341) that can corrupt a repository.We were caching
RepositoryDataserialized in the newestmetadata format. This lead to a confusing situation where
numeric shard generations would be cached in
ShardGenerationsthat were not written to the repository because the repository
or cluster did not yet support
ShardGenerations.In the case where shard generations are not actually supported yet,
these cached numeric generations are not safe and there's multiple
scenarios where they would be incorrect, leading to the repository
trying to read shard level metadata from index-N that don't exist.
This commit makes it so that cached metadata is always in the same
format as the metadata in the repository.
Example broken scenario:
RepositoryDatawith some numeric shard generations-> at this point the shards that were moved to a new generation by the data node are already not writable any more though this can be fixed by re-adding the repository or restarting the master node still at this point.
The situation gets worse though:
RepositoryDatathat is written is based off of the cached version. Corrupting the repository since there is no fail-safe for this in the snapshot delete logic (will open a separate PR to add one).