[
https://issues.apache.org/jira/browse/SOLR-9375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15407219#comment-15407219
]
Varun Thacker commented on SOLR-9375:
-------------------------------------
Hi Ronald,
The problem with not making local backups is - what if the replica has moved to
another machine? how will we restore then?
The idea of local copy works well if we have a set number of servers and the
replicas for a collection are assigned to a server and doesn't change .
Hence we went with the NFS mount option so it could cater to more use cases
where the NFS mount stays , but machines can change over time etc.
I don't think the repository concept helps much here. Repositories are designed
to make the underlying storage pluggable i.e before SOLR-7374 only NFS mount
worked. But now we have HDFS support as well. And one could write a S3
repository etc.
For your use case I would recommend to use the Standalone Mode backup/restore
APIs -
https://cwiki.apache.org/confluence/display/solr/Making+and+Restoring+Backups
It
You would need to change gettingstarted with collectionName_shardX_replicaY and
call backup / restore individually on each replica of your collection
> 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]
