-
Notifications
You must be signed in to change notification settings - Fork 25.2k
Auto import dangling indices #2067
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
Comments
mark |
What is the intended behavior? We are seeing the following: running a cluster of 2 data nodes, and a Java application which uses an instance of a Client as a non-data node, we index some documents into several different indices, and shutdown the application. Then we issue a delete all indexes request: curl -XDELETE 'http://localhost:9200/', and can see the command was acknowledged and performed. The next time we run the application, we see the following - all indexes being recreated on one of the data nodes, even tho the Java app was hosting a non-data node, and they were explicitly marked for deletion on the data node: [2012-10-03 12:17:41,131][INFO ][cluster.service ] [Firearm] added {[Landslide][pT7UUb00TNWYBTeluR6mcw][inet[/192.168.1.8:9302]],}, reason: zen-disco-receive(join from node[[Landslide][pT7UUb00TNWYBTeluR6mcw][inet[/192.168.1.8:9302]]]) It's either I'm missing something, or it is an issue with both a non-data node storing data it shouldn't and no tombstones are kept. |
Hi kimchy, I would like to make Auto import dangling indices to "no", can you please help me out here how to do it and which file i need to change. Can you tell me the file location. |
@gvkrf Please do not use GitHub issues to ask questions about how to use Elasticsearch. Please head to our discussion site http://discuss.elastic.co/ and ask your question there. |
Dangling indices happen when a node that has several indices stored locally, joins a cluster and those local indices do not exists in the cluster metadata. This usually does not happen, especially not with proper gateway.recover_after_nodes flag, but still, users can by mistake get into this state.
A new setting
gateway.local.auto_import_dangled
setting, with possible values ofno
(never import dangling indices, but also delay the delation of them),yes
(import dangling indices), andclosed
(import dangling indices, but in closed state). The default value isyes
.The text was updated successfully, but these errors were encountered: