incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From go canal <goca...@yahoo.com>
Subject Re: replication over internet
Date Fri, 25 Sep 2009 23:57:25 GMT
that's really good news, thanks !

 rgds,
canal




________________________________
From: Adam Kocoloski <kocolosk@apache.org>
To: user@couchdb.apache.org
Sent: Friday, September 25, 2009 9:15:03 PM
Subject: Re: replication over internet

On Sep 25, 2009, at 6:42 AM, go canal wrote:

> hello,
> Looking at the replication wiki, I assume that the current implementation is for supporting
high availability - so machines are likely in the same local network.
> 
> What if I want to replicate to the remote sites ?

CouchDB's replication model is certainly geared for that as well.  In fact, it's designed
to work between servers that are only occasionally connected, too.

> At least two requirements I can think of:
> * (must) first, we need to support HTTPS not only HTTP, unless the data is already encrypted.

This is supported in the upcoming 0.10 release.

> * (want) secondly, schedule the replication - I do not know how internally replication
is done, with every change, or already use some buffer for batch process. but better if we
can configure when to replicate, how often, etc. for example, hourly, etc. My customer asked
me to avoid as much network activities as possible during certain period of time during the
day. of cause, they maybe able to look into their infrastructure and applications .... but
nice if we can configure something.

By default, CouchDB replication is "one-and-done" -- its replicates all the updates that are
missing on the target at the moment you start the replication, then stops.  If you pass the
"continuous":true option in the POST to _replicate, Couch will continue to replicate all updates
immediately.

For the scheduled replication service you describe above, we recommend triggering normal replications
with cron.  Down the line CouchDB might grow its own internal cron, but we didn't want to
reinvent the wheel.  Best,

Adam


      
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message