[
https://issues.apache.org/jira/browse/OAK-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13882836#comment-13882836
]
Jukka Zitting commented on OAK-1357:
------------------------------------
bq. This would give you a backup, but how do you restore it? Grab the latest DB
backup you have and run #restore(checkpoint).
Why would you need the {{restore(checkpoint)}} call in that case? You've
already restored the database from a backup. Presumably the database backup is
already consistent, i.e. it doesn't contain partially committed transactions,
which is the case for pretty much all known databases, including MongoDB. When
using such an external backup mechanism, you shouldn't even need to
{{checkpoint()}} the state of the Oak repository, as the recovery would look to
Oak exactly like a normal restart.
bq. I think the diff states should be reversed
No, the example shows how to go back in time, which is why the states are in
reverse order.
> 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)
