lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Varun Thacker (JIRA)" <>
Subject [jira] [Updated] (SOLR-6637) Solr should have a way to restore a core
Date Sat, 07 Feb 2015 08:32:35 GMT


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".


bq. Considering that a restore is a full replace of the older index, we can just use the same 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 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/
./solr/core/src/java/org/apache/solr/handler/ ./solr/core/src/java/org/apache/solr/handler/}}

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:
>             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
> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message