[
https://issues.apache.org/jira/browse/SOLR-9055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15269224#comment-15269224
]
Hrishikesh Gadre commented on SOLR-9055:
----------------------------------------
bq. It was suggested early in SOLR-5750 that the location param should have a
protocol/impl scheme URL prefix (assume file:// if not specified). That may
help the Overseer?
I thought about that and the BackupRepositoryFactory implementation (in my
patch) is using the the "scheme" of the URI to instantiate the correct
repository instance. The problem is that the repository implementation may
require additional parameters (e.g. S3 credentials, kerberos settings for HDFS
etc.) which will also need to be propagated from client to the overseer AND
from overseer to the individual cores. We will also need to come up with a
mechanism to specify these "extra" parameters. Instead of providing such
complicated interface to the users, I am thinking to provide a "registry" of
repositories configured across the cluster. The users will need to configure
the registry once and just refer to it by name. In this case Solr will already
have all the information necessary to communicate with the repository (which
can be a file-system or an object store).
bq. I think what this comes down to is, should we re-use the Lucene Directory
API for moving data in/out of the backup location, or should we use something
else.
Yes I think it is possible to use Lucene Directory implementation without
requiring a different "Repository" interface. Currently we don't have Directory
implementation available for S3 though. Should we do that?
> Make collection backup/restore extensible
> -----------------------------------------
>
> Key: SOLR-9055
> URL: https://issues.apache.org/jira/browse/SOLR-9055
> Project: Solr
> Issue Type: Task
> Reporter: Hrishikesh Gadre
> Assignee: Mark Miller
> Attachments: SOLR-9055.patch
>
>
> SOLR-5750 implemented backup/restore API for Solr. This JIRA is to track the
> code cleanup/refactoring. Specifically following improvements should be made,
> - Add Solr/Lucene version to check the compatibility between the backup
> version and the version of Solr on which it is being restored.
> - Add a backup implementation version to check the compatibility between the
> "restore" implementation and backup format.
> - Introduce a Strategy interface to define how the Solr index data is backed
> up (e.g. using file copy approach).
> - Introduce a Repository interface to define the file-system used to store
> the backup data. (currently works only with local file system but can be
> extended). This should be enhanced to introduce support for "registering"
> repositories (e.g. HDFS, S3 etc.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
