couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
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<> 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":""}'
>> 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":"",
>> "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

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

View raw message