[
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: [email protected]
For additional commands, e-mail: [email protected]
