Really? This should not happen I think. Could you reproduce it and open an issue with a scenario we can use to reproduce this?
David
Le 4 févr. 2015 à 23:06, André Hänsel andre@webkr.de a écrit :
That is indeed helpful.
However, I just noticed that it's not even necessary - the repository is still created, despite the error 500 returned.
On Wednesday, February 4, 2015 at 8:11:12 AM UTC+1, David Pilato wrote:
When we check the repository, we wait for the move to be done before trying to read the file from another node.BTW you can pass ?verify=false when you create the repo so it won't be checked.
David
Le 4 févr. 2015 à 07:52, André Hänsel an...@webkr.de a écrit :
Ok, but that has nothing to do with the write being synchronous (blocking) or asynchronous, does it?
On Wednesday, February 4, 2015 at 7:12:17 AM UTC+1, David Pilato wrote:
Shared FS needs to support Atomic moves. This is something checked when you create the repo and I think it could give you the message you have seen.David
Le 4 févr. 2015 à 07:04, André Hänsel an...@webkr.de a écrit :
Is this snapshot type just for nodes that run on the same machine? The Elasticsearch guide didn't really say anything about requirements to that filesystem in terms of atomicity, delay, locking, etc.
If Elasticsearch doesn't wait, you would need a shared filesystem where the fopen call blocks until it is replicated on all nodes. That would mean DRBD in Protocol A (LINBIT Software Download Page For LINSTOR And DRBD Linux Driver) wouldn't work. (Doesn't won't for dual-primary anyway, but that's not the point here.) Lsyncd or csync2 wouldn't work either. Or any FUSE filesystem based on S3, FTP, SSH, etc.
On Wednesday, February 4, 2015 at 6:45:18 AM UTC+1, David Pilato wrote:
Elasticsearch does not really wait. I mean that once a file is created on a shared FS it should be visible immediately on other nodes that share the same FS.Is your FS really shared on both nodes using the same mount point?
David
Le 4 févr. 2015 à 01:18, André Hänsel an...@webkr.de a écrit :
I'm trying to set up a snapshot repository to get a consistent backup (in order to use elasticsearch as primary data store).
When I try to create the repository, I get an error 500:
error: "RemoteTransportException[[Jack Kirby][inet[/10.133.199.7:9300]][cluster:admin/repository/put]]; nested: RepositoryVerificationException[[hurz] [_kKn5dODRzmPOhi05U59yg, 'RemoteTransportException[[Box][inet[/10.133.199.63:9300]][internal:admin/repository/verify]]; nested: RepositoryVerificationException[[hurz] store location [/tmp/ess] is not shared between node [[Box][_kKn5dODRzmPOhi05U59yg][esstest-a][inet[/10.133.199.63:9300]]] and the master node]; ']]]; "I can see with inotify that it creates two files like
tests-yOvEwIjQQP6rs_xqf-iFAQ-master
tests-yOvEwIjQQP6rs_xqf-iFAQ-WKG7i2KATZWalcDgwEfX8QBut those two files are removed immediately after, before they even arrive on the other node.
How long does elasticsearch wait for the files to appear on the other node before it decides that the store location "is not shared"?
In general I think having to have a shared filesystem for backup takes away some of the advantage of elasticsearch replicating itself. If I have a shared filesystem anyway, I could just put the index there. For indexes that are not continuously updated of course.
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/02af3bdc-f5e2-418d-b8c9-2aeeaf245a4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/e44737d6-8fdf-486f-883c-33435e8b9cd4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearc...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/4d274fc6-7612-4482-8264-6293c3ad6b02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/f6a9f812-6656-46e0-ab5f-f212671b29d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/36BBB027-811E-44BD-A9C5-36F9461F468B%40pilato.fr.
For more options, visit https://groups.google.com/d/optout.