We've already got replication, _all_docs and some really robust on-disk consistency properties. For shuttling raw database files between servers, wouldn't rsync be more efficient (and fit better within existing sysadmin security/deployment structures)? -nvw
On Aug 16, 2011, at 9:55 AM, Paul Davis wrote: > Me and Adam were just mulling over a similar endpoint the other night > that could be used to generate plain-text backups similar to what > couchdb-dump and couchdb-load were doing. With the idea that there > would be some special sauce to pipe from one _dump endpoint directly > into a different _load handler. Obvious downfall was incremental-ness > of this. Seems like it'd be doable, but I'm not entirely certain on > the best method. > > I was also considering this as our full-proof 100% reliable method for > migrating data between different CouchDB versions which we seem to > screw up fairly regularly. > > +1 on the idea. Not sure about raw couch files as it limits the wider > usefulness (and we already have scp). > > On Tue, Aug 16, 2011 at 10:24 AM, Jan Lehnardt <j...@apache.org> wrote: >> This is only slightly related, but I'm dreaming of /db/_dump and >> /db/_restore endpoints (the names don't matter, could be one with GET / PUT) >> that just ships verbatim .couch files over HTTP. It would be for admins >> only, it would not be incremental (although we might be able to add that), >> and I haven't yet thought through all the concurrency and error case >> implications, the above solves more than the proposed problem and in a very >> different, but I thought I throw it in the mix. >> >> Cheers >> Jan >> -- >> >> On Aug 16, 2011, at 5:08 PM, Robert Newson wrote: >> >>> +1 on the intention but we'll need to be careful. The use case is >>> specifically to allow verbatim migration of databases between servers. >>> A separate role makes sense as I'm not sure of the consequences of >>> explicitly granting this ability to the existing _admin role. >>> >>> B. >>> >>> On 16 August 2011 15:26, Adam Kocoloski <kocol...@apache.org> wrote: >>>> One of the principal uses of the replicator is to "make this database look >>>> like that one". We're unable to do that in the general case today because >>>> of the combination of validation functions and out-of-order document >>>> transfers. It's entirely possible for a document to be saved in the >>>> source DB prior to the installation of a ddoc containing a validation >>>> function that would have rejected the document, for the replicator to >>>> install the ddoc in the target DB before replicating the other document, >>>> and for the other document to then be rejected by the target DB. >>>> >>>> I propose we add a role which allows a user to bypass validation, or else >>>> extend that privilege to the _admin role. We should still validate >>>> updates by default and add a way (a new qs param, for instance) to >>>> indicate that validation should be skipped for a particular update. >>>> Thoughts? >>>> >>>> Adam >> >>
