Ronald Braun created SOLR-9375:
----------------------------------
Summary: 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]
