couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: continuous replication API discussion
Date Tue, 11 Aug 2009 21:57:13 GMT
On Tue, Aug 11, 2009 at 11:40 AM, Damien Katz<damien@apache.org> wrote:
>
> On Aug 10, 2009, at 4:09 PM, Adam Kocoloski wrote:
>
>> Hi folks, I committed some code today to enable continuous replication
>> between CouchDB servers.  I could use some help defining the client API,
>> though.  To recap, replication has always been triggered RPC-style by a
>> request like
>
> Yeehaw!!!
>
>>
>> POST /_replicate -d '{"source":"foo", "target":"http://example.com/bar"}'
>>
>> this request would block until the replication had completed and then
>> you'd get a 200 response code and something like
>>
>> {
>>  "ok": true,
>>  "session_id": uuid(),
>>  "source_last_seq": 1234,
>>  "history":[....]
>> }
>>
>> Well, it doesn't make too much sense to do the same with continuous
>> replication because the response will never arrive.  Basically, I think we
>> need to answer the following questions:
>>
>> 1. How does a user trigger a continuous replication?  Simplest extension
>> of the current API would be
>>
>> POST /_replicate -d '{"source":"foo", "target":"http://example.com/bar",
>> "continuous":true}'
>>
>> 2. How does the server respond to that request?  Perhaps a "202 Accepted"
>> along with the replication ID?
>>
>> 3. How does a client monitor the progress of a continuous replication?
>>  The replication will show up in _active_tasks, but I'd like to have a way
>> to get all the history information.  If we return the replication ID the
>> client could GET the _local doc with that ID, but we probably want a
>> resource that's a bit easier to discover.
>
> Maybe a special HTTP call to get replication info?
>
>
>>
>> 4. How can we configure replications that survive a server restart?
>
> I think I'd like to see a replication config database, and a constant
> replicator config process that reads the config info at server start and
> starts the continuous replications.  It monitors the config db for changes
> and as new settings are written spawns, restarts or shuts down replication
> tasks.
>

I think this is a great idea. The Futon interface for configuring this
will probably take a lot of the mystery out of replication for our
users.

Bonus that using a config db suddenly makes our replicator trivial to
configure across a cluster with tools like Chef.


> I can't think of a use case where it's okay to have it *not* survive a
> restart. Continuous replications aren't something you do temporarily, I
> think.
>
> -Damien
>
>>
>> Adam
>
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message