Fix Partial Snapshots Recording Spurious Errors #69150
Merged
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
If an index is deleted while a partial snapshot is running the behavior was not deterministic. If an index was deleted just as one of its shard snapshots was about to start then it would be recorded as a shard snapshot failure in the snapshot result and the snapshot would show up as `PARTIAL`. If the index delete however happened after the shard had been snapshotted, then the snapshot would show `SUCCESS`. In both cases however, the snapshot would contain the exact same data because the deleted index would become part of the final snapshot. Also, it was confusing that in the `PARTIAL` case, there would be errors recorded for shards the indices of which would not be part of the snapshot. This commit makes it such that not only are indices filtered from the list of indices in a snapshot but also from the shard snapshot errors in a snapshot entry so that the snapshot always shows up as `SUCCESS` because concurrent index deletes are not a failure but allowed in partial snapshots. Closes elastic#69014
original-brownbear
added
:Distributed Coordination/Snapshot/Restore
elasticmachine
added
the
Team:Distributed (Obsolete)
|
Pinging @elastic/es-distributed (Team:Distributed) |
|
Jenkins test this |
|
Thanks @TommyWind ! |
original-brownbear
pushed a commit
to original-brownbear/elasticsearch
that referenced
this pull request
Feb 22, 2021
If an index is deleted while a partial snapshot is running the behavior was not deterministic. If an index was deleted just as one of its shard snapshots was about to start then it would be recorded as a shard snapshot failure in the snapshot result and the snapshot would show up as `PARTIAL`. If the index delete however happened after the shard had been snapshotted, then the snapshot would show `SUCCESS`. In both cases however, the snapshot would contain the exact same data because the deleted index would become part of the final snapshot. Also, it was confusing that in the `PARTIAL` case, there would be errors recorded for shards the indices of which would not be part of the snapshot. This commit makes it such that not only are indices filtered from the list of indices in a snapshot but also from the shard snapshot errors in a snapshot entry so that the snapshot always shows up as `SUCCESS` because concurrent index deletes are not a failure but allowed in partial snapshots. Closes elastic#69014
original-brownbear
pushed a commit
to original-brownbear/elasticsearch
that referenced
this pull request
Feb 22, 2021
If an index is deleted while a partial snapshot is running the behavior was not deterministic. If an index was deleted just as one of its shard snapshots was about to start then it would be recorded as a shard snapshot failure in the snapshot result and the snapshot would show up as `PARTIAL`. If the index delete however happened after the shard had been snapshotted, then the snapshot would show `SUCCESS`. In both cases however, the snapshot would contain the exact same data because the deleted index would become part of the final snapshot. Also, it was confusing that in the `PARTIAL` case, there would be errors recorded for shards the indices of which would not be part of the snapshot. This commit makes it such that not only are indices filtered from the list of indices in a snapshot but also from the shard snapshot errors in a snapshot entry so that the snapshot always shows up as `SUCCESS` because concurrent index deletes are not a failure but allowed in partial snapshots. Closes elastic#69014
original-brownbear
added a commit
that referenced
this pull request
Feb 22, 2021
If an index is deleted while a partial snapshot is running the behavior was not deterministic. If an index was deleted just as one of its shard snapshots was about to start then it would be recorded as a shard snapshot failure in the snapshot result and the snapshot would show up as `PARTIAL`. If the index delete however happened after the shard had been snapshotted, then the snapshot would show `SUCCESS`. In both cases however, the snapshot would contain the exact same data because the deleted index would become part of the final snapshot. Also, it was confusing that in the `PARTIAL` case, there would be errors recorded for shards the indices of which would not be part of the snapshot. This commit makes it such that not only are indices filtered from the list of indices in a snapshot but also from the shard snapshot errors in a snapshot entry so that the snapshot always shows up as `SUCCESS` because concurrent index deletes are not a failure but allowed in partial snapshots. Closes #69014 Co-authored-by: Tamara Braun <[email protected]>
original-brownbear
added a commit
that referenced
this pull request
Feb 23, 2021
If an index is deleted while a partial snapshot is running the behavior was not deterministic. If an index was deleted just as one of its shard snapshots was about to start then it would be recorded as a shard snapshot failure in the snapshot result and the snapshot would show up as `PARTIAL`. If the index delete however happened after the shard had been snapshotted, then the snapshot would show `SUCCESS`. In both cases however, the snapshot would contain the exact same data because the deleted index would become part of the final snapshot. Also, it was confusing that in the `PARTIAL` case, there would be errors recorded for shards the indices of which would not be part of the snapshot. This commit makes it such that not only are indices filtered from the list of indices in a snapshot but also from the shard snapshot errors in a snapshot entry so that the snapshot always shows up as `SUCCESS` because concurrent index deletes are not a failure but allowed in partial snapshots. Closes #69014 Co-authored-by: Tamara Braun <[email protected]>
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.
If an index is deleted while a partial snapshot is running the behavior
was not deterministic.
If an index was deleted just as one of its shard snapshots was about to
start then it would be recorded as a shard snapshot failure in the
snapshot result and the snapshot would show up as
PARTIAL.If the index delete however happened after the shard had been
snapshotted, then the snapshot would show
SUCCESS.In both cases however, the snapshot would contain the exact same data
because the deleted index would become part of the final snapshot.
Also, it was confusing that in the
PARTIALcase, there would be errorsrecorded for shards the indices of which would not be part of the
snapshot.
This commit makes it such that not only are indices filtered from the
list of indices in a snapshot but also from the shard snapshot errors
in a snapshot entry so that the snapshot always shows up as
SUCCESSbecause concurrent index deletes are not a failure but allowed in
partial snapshots.
Closes #69014