[
https://issues.apache.org/jira/browse/SOLR-9375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408073#comment-15408073
]
Varun Thacker commented on SOLR-9375:
-------------------------------------
bq. he docs seems to make it sound like a suggestion more than not, but that
was probably my misreading.
I'll go over the docs and see if we can make it more clear
So the way it works is - the backup command goes to the overseer . Say the
location you specify is "/my/nfs/mount/solr_backup" and the backup name is
"backup1"
So under "/my/nfs/mount/solr_backup/backup1" , you'll see every shards indexes
, ZK data and a metadata file .
> 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]
