[
https://issues.apache.org/jira/browse/SOLR-9375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408054#comment-15408054
]
Ronald Braun commented on SOLR-9375:
------------------------------------
Hi Varun, thanks for the suggestions! We were originally looking at the
Standalone Mode methodology but were drawn to the new backup op since it seems
to package together more useful stuff in the backup. Your point about
restoration of local backups is a good one, and we were going to manage that
locally as part of our longer archiving process anyway, but I certainly agree
the shared design makes sense. I just didn't realize the shared endpoint was a
hard requirement for using collections api backup methodology -- the docs seems
to make it sound like a suggestion more than not, but that was probably my
misreading. The one oddity I thought from a design perspective was having
different nodes create the backup location and then use that location -- the
coordination between nodes seems to inject a failpoint into the process if
something goes wrong in their worldviews. But if you want to ensure the
overseer has access to the actual restoration location for restore, I guess it
kinda sorta makes sense that it is the one to create it. Anyway, all good,
thanks for your insights!
> 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]
