[
https://issues.apache.org/jira/browse/SOLR-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333537#comment-15333537
]
Varun Thacker commented on SOLR-7374:
-------------------------------------
Hi Hrishikesh,
Thanks for the updated patch! Looks good
While reviewing it I didn't understand one thing -
In {{ReplicationHandler#restore}} why are we always using
{{LocalFileSystemRepository}} and not reading any {{repository}} param?
Currently to backup/restore in standalone mode we use the replication handler (
https://cwiki.apache.org/confluence/display/solr/Making+and+Restoring+Backups+of+SolrCores
) . I think we should read the {{repository}} param and initialize accordingly.
The backup/restore operation that is in CoreAdminOperation was added as part of
SOLR-5750 for the Overseer to be able to call backup/restore on individual
cores.
I don't think this set of comments is entirely true. The first version of
backup which had been there for ages allowed an empty location param and
resorted to the cores data directory. It had nothing to do with shared file
systems . The back compat part is true though.
{code}
// Note - This logic is only applicable to the usecase where a shared
file-system is exposed via
// local file-system interface (primarily for backwards compatibility). For
other use-cases, users
// will be required to specify "location" where the backup should be stored.
{code}
Lastly you mentioned this in a previous comment
bq. This is a partial patch handling ONLY core level changes. The collection
level changes are being captured in the patch for SOLR-9055.
However {{TestHdfsBackupRestore}} added in this patch is a solr cloud test .
What other work is left for supporting collection level changes?
I only briefly looked at SOLR-9055 and couldn't tell why we need
ShardRequestProcessor etc.
I would think the only work required would be in CollectionsHandler to deal
with "location" , in OverseerCollectionMessageHandler the part where we
read/write the meta information and ZK configs?
> Backup/Restore should provide a param for specifying the directory
> implementation it should use
> -----------------------------------------------------------------------------------------------
>
> Key: SOLR-7374
> URL: https://issues.apache.org/jira/browse/SOLR-7374
> Project: Solr
> Issue Type: Bug
> Reporter: Varun Thacker
> Assignee: Mark Miller
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch,
> SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch
>
>
> Currently when we create a backup we use SimpleFSDirectory to write the
> backup indexes. Similarly during a restore we open the index using
> FSDirectory.open .
> We should provide a param called {{directoryImpl}} or {{type}} which will be
> used to specify the Directory implementation to backup the index.
> Likewise during a restore you would need to specify the directory impl which
> was used during backup so that the index can be opened correctly.
> This param will address the problem that currently if a user is running Solr
> on HDFS there is no way to use the backup/restore functionality as the
> directory is hardcoded.
> With this one could be running Solr on a local FS but backup the index on
> HDFS 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
