Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abort early on finding duplicate snapshot name in internal structures #29634

Merged
merged 1 commit into from
Apr 20, 2018

Conversation

ywelsch
Copy link
Contributor

@ywelsch ywelsch commented Apr 20, 2018

Adds a check in BlobstoreRepository.snapshot(...) that prevents duplicate snapshot names and fails the snapshot before writing out the new index file. This ensures that you cannot end up in this situation where the index file has duplicate names and cannot be read anymore .

Relates to #28906

@ywelsch ywelsch added >non-issue :Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs v7.0.0 v6.3.0 labels Apr 20, 2018
@ywelsch ywelsch requested a review from tlrx April 20, 2018 13:25
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed

@ywelsch ywelsch merged commit 6a4c5f3 into elastic:master Apr 20, 2018
ywelsch added a commit that referenced this pull request Apr 20, 2018
…#29634)

Adds a check in BlobstoreRepository.snapshot(...) that prevents duplicate snapshot names and fails 
the snapshot before writing out the new index file. This ensures that you cannot end up in this
situation where the index file has duplicate names and cannot be read anymore .

Relates to #28906
DaveCTurner added a commit to DaveCTurner/elasticsearch that referenced this pull request Mar 23, 2021
Today we prevent creating a shard snapshot whose name matches one that
already exists (elastic#29634) but it's possible to end up with duplicate
snapshot names anyway if the `index-N` file is unreadable and the
fallback which reads all the `snap-UUID.dat` files encounters two with
the same name, perhaps due to some earlier failure. This results in
writing a broken `index-N` file that contains duplicate keys, which
completely breaks the repository.

This commit fails the shard snapshot without writing the broken
`index-N` file in this situation, on the assumption that the
unreadability of the existing `index-N` file is only temporary.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants