[
https://issues.apache.org/jira/browse/SOLR-9375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408072#comment-15408072
]
Shalin Shekhar Mangar commented on SOLR-9375:
---------------------------------------------
NFS can cache directory listings locally so it is dangerous to rely on the fact
that a node has created a folder that can be used immediately on a different
node. I think that we should always attempt to create the backup folder on all
nodes which are actually performing the backup. In the worst case you will get
an exception saying that the directory already exists. It will also remove the
hard requirement of a shared mount point which we have no way of enforcing
anyway.
> Collections API BACKUP distribution of responsibilities is odd
> --------------------------------------------------------------
>
> Key: SOLR-9375
> URL: https://issues.apache.org/jira/browse/SOLR-9375
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 6.1
> Reporter: Ronald Braun
> Priority: Minor
>
> We are running a four node solr cloud setup in 6.1.0 and have been playing
> around with the new BACKUP command out of collections api. We experienced an
> oddity that may be by design, but I thought I would raise it as a potential
> issue as it seems non-optimal.
> My understanding is that the backup command assumes a shared NFS mount that
> is available across all nodes, and in that configuration things work fine in
> our testing. But we were looking at an alternate configuration where each
> solr node has a local mount (to a local drive). Our hope was that the backup
> process would cause the collection leader to backup the collection to its
> local drive. However, in practice this fails with a "directory non-existent
> error". What appears to be happening is that overseer node is creating the
> backup directory on its local mount, and then forwarding the request to the
> collection leader (which happens to be a different node) for actual backup
> execution, which then fails because the created directory doesn't exist for
> it. In the configuration where everyone shares a remote mount, this isn't
> problematic since the two nodes are operating on the same endpoint.
> My expectation would be that the collection leader would create the local
> directory and then backup to that directory, which would support this
> configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
