You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Varun Thacker (JIRA)" <ji...@apache.org> on 2018/09/21 21:33:00 UTC

[jira] [Updated] (SOLR-9239) Deprecate backup/restore via replication handler in favour of an equvalent core admin api

     [ https://issues.apache.org/jira/browse/SOLR-9239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Varun Thacker updated SOLR-9239:
--------------------------------
    Component/s: Backup/Restore

> Deprecate  backup/restore via replication handler in favour of an equvalent core admin api
> ------------------------------------------------------------------------------------------
>
>                 Key: SOLR-9239
>                 URL: https://issues.apache.org/jira/browse/SOLR-9239
>             Project: Solr
>          Issue Type: Improvement
>          Components: Backup/Restore
>            Reporter: Varun Thacker
>            Priority: Minor
>
> In SOLR-5750 we added core backup/restore hooks via the core admin API . This was done at the time to leverage the backup/restore code from the cloud classes . A discussion on why we have two ways for core backup/restore came up in SOLR-7374 . 
> Currently we document core backup/restore only via the replication handler. I think we should move in favour of it being a core admin operations. Here are some of the reasons why I think thats a good idea :
> - SolrCloud backup/restore is implemented as a collection api. The logical equivalent of it for standalone should be core admin and not replication handler . 
> - More importantly core admin supports async calls. So using the backup/restore api will be a lot cleaner. We don't need a separate backup/ restore status API . 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org