Hi, I'm back trying to gather some feedback from the people involved in the MongoDB store impl.
This is about creating a backup of the current repository using a native backup tool, a tool that is running at databasel level. It was my understanding that if you run a (non blocking) backup at any given time, you might catch a repository in an inconsistent state (large transactions half-way completed maybe?), so you might need a way to mark the latest stable head before basically copying everything. Next on restore you would simply need to reset the head to the last known stable state and you get the full circle. I've found that the checkpoint mechanism we use for the async indexing fits this model nicely, and I was planning on using it in this context as well: marking the last state with a checkpoint, then using the same checkpoint id as a reference for the restore. This would work both in the case of a MongoDB store (also the RDB one) but also in the cases where the repository is too big and out backup code cannot handle it efficiently (think huge repo + file system snapshots). This assumption was challenged via OAK-1357 with the idea that the MongoDB backup can already produce consistent (non-blocking) backups so there's nothing to be done in this area. Also restoring means only replacing the old db with the backup one. If this is true, I'm as happy as it gets, I can already close down a bunch of issues :) but I want clear confirmation that this is in fact the way it works and that everybody agrees with it and so there are no loose ends. thanks for your attention, alex On Mon, Jan 27, 2014 at 1:22 PM, Alex Parvulescu <[email protected]>wrote: > Hi, > > I've created OAK-1357 asking for a new method on the NodeStore apis: > 'restore', please add your thoughts to the issue. > > thanks, > alex >
