[
https://issues.apache.org/jira/browse/OAK-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882830#comment-13882830
]
Alex Parvulescu commented on OAK-1357:
--------------------------------------
bq. Note that a typical restore from backup involves recreating the entire
repository from scratch, not moving back in time within an existing and fully
functional repository
Right, I'm talking about running an external backup in the context of the
mongo store (or rdb store), which would look like: 1st checkpoint, 2nd run an
external backup tool specific to the nodestore impl.
This would give you a backup, but how do you restore it? Grab the latest DB
backup you have and run #restore(checkpoint).
I see the point you are trying to make, and I agree with keeping the apis
simple. I guess we can put this code in a sort of helper method (it is generic
enough). What we might also lose here is the opportunity to optimize based on
mk impl (skip the diff if possible).
By the way, I think the diff states should be reversed, as you are trying to
recover to a previous state :)
> Add 'restore' method to NodeStore apis
> --------------------------------------
>
> Key: OAK-1357
> URL: https://issues.apache.org/jira/browse/OAK-1357
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: Alex Parvulescu
> Assignee: Alex Parvulescu
>
> OAK-762 introduced a checkpoint mechanism which allows for the creation of a
> snapshot of the current state, referenced by a string.
> Other than internally for the async indexing I'd like to leverage this in the
> case of an external (non blocking!) backup process (for both mongomk and
> rdbstore) and probably for the tarmk simple failover scenario.
> What is currently missing is an option to restore the current state to a
> captured snapshot, which is the point of this issue.
> I'm proposing we add a _ #restore(String checkpoint)_ method to the NodeStore
> apis which resets the current head to the provided state.
> This could probably throw an exception in the case the provided checkpoint
> doesn't exist, and it would also fail ongoing transactions as they don't
> apply anymore.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
