On Fri, Jun 17, 2011 at 05:07, Patrick Barnes <[email protected]> wrote: > I would *really* like to have functionality like this... > > Perhaps a mechanism to manage serial snapshots of the db's state? > > It seems to me be that maybe a snapshot could just be a header that does not > get compacted away, and that one could: > - 'Roll-back' the database to a given snapshot. (Undo, but not necissarily > Redo) > - Generate, save, or apply a delta between two snapshots. > - Clear snapshots when no longer needed, so they are compacted away. >
It'd require a few changes, but theoretically possible. We just move from having one valid db header to several headers. It's a bit like root sets in garbage collection. > Disclaimer - I may not know what I'm talking about. > > -Patrick > > On 17/06/2011 4:58 PM, Dave Cottlehuber wrote: >> >> On 17 June 2011 14:55, Thomas Hommers<[email protected]> wrote: >>> >>> Hi Nils, >>> >>>> CouchDB uses an append-only file format, so you can safely use tools >>>> like cp or rsync to easily create a point-in-time snapshot of a database. >>> >>> That were my thoughts. >>> >>> So it will be replication, then filesystem snapshot of the database with >>> rsync to store different versions to travel back in time if necessary. >>> >>> Does anybody has some other idea? Does anybody know how to "cut" the end >>> of a couchDB file ? >>> >>> Regards >>> Thomas >>> >> >> Hi Thomas, >> >> Good approach. >> >> Its not clear why you want to cut the end of a DB file but dd or >> anything like that will do the job. CouchDB will scan back from the >> end to find the last valid header so an accurate snip is not required. >> >> I've considered having a replication endpoint that simply logs >> _changes to an audit file, something like this would allow you to >> replay a specific change if required. >> >> A+ >> Dave >> >
