[
https://issues.apache.org/jira/browse/SOLR-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15334207#comment-15334207
]
Hrishikesh Gadre commented on SOLR-7374:
----------------------------------------
[~varunthacker] Thanks for the comments.
bq. In ReplicationHandler#restore why are we always using
LocalFileSystemRepository and not reading any repository param?
The reason is that ReplicationHandler is not configured with the CoreContainer
(which is required to fetch the repository configuration). Also building two
parallel implementations for the same functionality doesn't quite make sense.
Can we instead make the Core level Backup/Restore APIs public (i.e. not limited
to Solrcloud)? This allows users to keep using ReplicationHandler in case of
local file-system but if they need to integrate with other file-systems they
can move to these core level APIs. If feasible, we can even deprecate (and
remove) backup/restore APIs from ReplicationHandler in future.
bq. However TestHdfsBackupRestore added in this patch is a solr cloud test .
What other work is left for supporting collection level changes?
I had to implement this test as a "cloud" test so as to enable testing these
core level operations (since these operations are enabled only in the cloud
mode). The collection-level changes include,
- Backup/restore collection metadata
- Check the version compatibility during restore
- Strategy interface to define "how" backup operation is performed (e.g.
copying the index files vs. a file-system snapshot etc.)
bq. I only briefly looked at SOLR-9055 and couldn't tell why we need
ShardRequestProcessor etc.
The main reason is to implement a index backup strategy. Also in general
processing shard requests is such a common functionality that embedding it in
the OverseerCollectionMessageHandler doesn't quite seem write (from modularity
perspective).
bq. Also i found ZkStateReader#BACKUP_LOCATION constant. We should merge those
two constants I guess
Make sense. Let me do that.
> 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: [email protected]
For additional commands, e-mail: [email protected]
