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

Jump to bottom

Dangling Indices should not be imported if a tombstone exists for the same Index UUID #18249

Closed
abeyad opened this issue May 10, 2016 · 0 comments
Closed

Dangling Indices should not be imported if a tombstone exists for the same Index UUID #18249

abeyad opened this issue May 10, 2016 · 0 comments
Assignees
@abeyad
Labels
>bug :Distributed/Distributed A catch all label for anything in the Distributed Area. If you aren't sure, use this one. v5.0.0-alpha3

Comments

@abeyad
Copy link

abeyad commented May 10, 2016 •
edited

A somewhat rare but nevertheless problematic scenario can occur if a data folder containing a deleted index is copied over to a node. Imagine the following steps:

  1. We have a one node in the cluster, A
  2. A creates an index called idx with UUID xyz.
  3. The data directory for node A is copied to some external location.
  4. idx is deleted from the cluster.
  5. Start up a new node B in the cluster
  6. After B has started up, copy the data directory previous put in an external location to the data directory for B
  7. Start a new node C, just in order to trigger a cluster state update.

At this point, the previously deleted idx with UUID xyz is imported into the index as a dangling index, even though a tombstone exists for it in the cluster state. This leads to a very confusing situation where the index exists in the cluster state and at the same time, there is a tombstone for it. Also, when the node restarts, it will check the tombstones, see the index is deleted, so delete it - that means the index re-appeared in the cluster state for some time but will be deleted again upon node restart.

Also, note that this problem does not occur if the data directory is copied before B is started, because in that case on node startup, the tombstones are checked so the index is not permitted to be imported as dangling.
@abeyad abeyad self-assigned this May 10, 2016
@abeyad abeyad mentioned this issue May 10, 2016
Closed
abeyad pushed a commit to abeyad/elasticsearch that referenced this issue May 11, 2016
Dangling indices are not imported if a tombstone for the same index
3a87d29 
(same name and UUID) exists in the cluster state.  This resolves a
situation where if an index data folder was copied into a node's data
directory while the node is running and that index had a tombstone in
the cluster state, the index would still get imported.

Closes elastic#18250
Closes elastic#18249
@abeyad abeyad closed this as completed in 5189eb4 May 11, 2016
@s1monw s1monw mentioned this issue Jul 18, 2016
Closed
@clintongormley clintongormley added :Distributed/Distributed A catch all label for anything in the Distributed Area. If you aren't sure, use this one. and removed :Cluster labels Feb 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@abeyad abeyad

Labels
>bug :Distributed/Distributed A catch all label for anything in the Distributed Area. If you aren't sure, use this one. v5.0.0-alpha3
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Dangling indices are not imported if a tombstone for the index exists abeyad/elasticsearch
2 participants
@clintongormley @abeyad