[
https://issues.apache.org/jira/browse/SOLR-9375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker closed SOLR-9375.
-------------------------------
Resolution: Won't Fix
> 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]
