[jira] [Updated] (SOLR-6637) Solr should have a way to restore a core

["Varun Thacker (JIRA)" <ji...@apache.org>]

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

Varun Thacker updated SOLR-6637:
--------------------------------
    Attachment: SOLR-6637.patch

Thanks Shalin for the review! I'm sorry it took this long for me to resume working on this.

Updated patch.

bq. The usage of restoreLock is wrong. If you issue a second restore then you'll get a IllegalMonitorStateException. The thread which acquires the lock must be the one which releases it.So just calling unlock from another request thread won't work. The RestoreCore thread must be the one to acquire and release the lock (in a finally clause)

The restore lock is acquired and unlocked by the RestoreCore thread.

bq. You should cancel the future interruptibly in the close hook. Just executor service's awaitTermination is not enough.

Changed it to {{ExecutorUtil.shutdownNowAndAwaitTermination(restoreExecutor);}}

bq. If restoreFuture is null (no restore has ever been requested), the restore status will return "in progress".

Fixed.

bq. Considering that a restore is a full replace of the older index, we can just use the same index.properties method that SnapPuller uses to ask SolrCore to reload with a new index directory. That would eliminate the copying around files to the index directory.

Files a copied over to a new restore directory and the using the index.properties method we switch the writer/searcher to this directory. If the same backed up segment files is present in the current index directory then that is used as the source for copying. 

bq. We should be able to rollback to original state (old directory) if the new index fails integrity checks.
It rolls back to the original index if we are uable to open the restored index. 



Spent a few hours further refactoring SnapPuller so that RestoreCore could use the index diff copying logic in there. But then I realized that SnapPuller always assumes that the source it's fetching from is always ahead of it's current state ( so we don't need to do cleanups if copying into the same directory fails). This would always not be the case when Restoring a core so decided not to go down that path.

Tests passed and precommit passes after this {{svn propset svn:eol-style native ./solr/core/src/java/org/apache/solr/handler/OldBackupDirectory.java ./solr/core/src/java/org/apache/solr/handler/ReplicationUtils.java ./solr/core/src/java/org/apache/solr/handler/RestoreCore.java}}

We'll need a slightly different patch for 5x which takes back-compat into consideration while restoring of files in {{RestoreCore.doRestore()}}

> Solr should have a way to restore a core
> ----------------------------------------
>
>                 Key: SOLR-6637
>                 URL: https://issues.apache.org/jira/browse/SOLR-6637
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Varun Thacker
>         Attachments: SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch, SOLR-6637.patch
>
>
> We have a core backup command which backs up the index. We should have a restore command too. 
> This would restore any named snapshots created by the replication handlers backup command.
> While working on this patch right now I realized that during backup we only backup the index. Should we backup the conf files also? Any thoughts? I could separate Jira for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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