incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Delete replication history
Date Sat, 24 Dec 2011 12:46:18 GMT
I believe Jim is referring to the replication checkpoint document
(which does indeed include 'historical' information). Jim is also
correct in that the presence of this document will prevent a full
re-replication when the target's validate_doc_update function is
altered.

Jim, the replication checkpoint document is named in the way:
/dbname/_local/<hash>. You should be able to see this document being
written to in the logs and the <hash> portion is also the value you
get back when POST'ing to _replicate (and the one shown in
_active_tasks). Delete the document in the usual fashion and
replication will do over from the start.

B.



On 24 December 2011 11:56, Dave Cottlehuber <dave@muse.net.nz> wrote:
> On 24 December 2011 02:30, Jim Klo <jim.klo@sri.com> wrote:
>> Trying to test a validate_doc_update function for use in replication.
>>
>> Is there a way to reset or delete the replication history so I don't have to continuously
recreate my target db?
>>
>> Thanks,
>>
>> - Jim
>
> Jim,
>
> There's no such thing as a replication history, only replicated
> documents. So you have a few choices;
>
> Recreate your db if you're starting from scratch this is as simple as
> an additional line in your test script, curl -X DELETE $DB ; curl -X
> PUT $DB.
>
> If you're not starting from scratch, then you can simply copy the
> fresh db somewhere as a backup, and re-copy it back with, say, rsync,
>
> You may find it easier to start a js interpreter up and work through
> the validation function directly, using the process outlined in
> http://wiki.apache.org/couchdb/Troubleshooting#Map.2BAC8-Reduce_debugging
> obviously you'll need to get a sample userCtx as well. I would think
> you can use the same logging function as the view server "log(stuff);"
> to do this. Note this is not for use on production DBs due to heavy
> perf impact.
>
> Pro-tip: don't forget to accept all _deleted docs through your
> function to ensure MVCC continues to work as expected.
>
> A+
> Dave

Mime
View raw message