[
https://issues.apache.org/jira/browse/OAK-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13958761#comment-13958761
]
Amit Jain commented on OAK-1500:
--------------------------------
Tested the following scenarios by following the backup restore for mongoo db
using [mongodump/mongorestore utility |
http://docs.mongodb.org/manual/tutorial/backup-small-sharded-cluster-with-mongodump/].
This was tested with a small 2 shards setup, by following the [mongo shard
setup | http://docs.mongodb.org/manual/tutorial/deploy-shard-cluster/]. But ids
being provided by the test redirected the writes to only one shard.
* Backup after a node being shutdown and restored.
* Large writes happening and randomly taking a backup, and then restoring the
db.
With the _lastRev recovery in place the start of the node after the backup
looked good and in a consistent state. With reads/writes succeeding and
_lastRev of root getting updated to the revision of the latest node written.
> Verify restore to revision on MongoNS
> -------------------------------------
>
> Key: OAK-1500
> URL: https://issues.apache.org/jira/browse/OAK-1500
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
> Reporter: Alex Parvulescu
> Assignee: Chetan Mehrotra
> Priority: Critical
> Fix For: 0.20
>
>
> Following the discussion on OAK-1339, the backup will be controlled from
> Mongo directly, but we still need to verify 2 things:
> - ongoing transactions will be discarded on restore, the head has to point
> to the latest stable revision
> - as an added benefit, the restore could happen to an older revision (see
> the sharded setup where a node can get ahead of the others between the moment
> the backup starts and when it will finish across the board)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
