couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blair Zajac <>
Subject Re: Replication and new user questions
Date Wed, 26 Aug 2009 20:33:49 GMT
Hi Adam,

Thanks for the quick reply, I appreciate it.

I neglected to mention that we're running trunk r807360.

Replies inline below.

Adam Kocoloski wrote:
> Hi Blair, all good questions, I'll try to answer inline:
> On Aug 25, 2009, at 5:10 PM, Blair Zajac wrote:
>> 1) What's the most robust automatic replication mechanism?  While 
>> continuous replication looks nice, I see there's some tickets open 
>> with it and that it has issues with four nodes.  Is a more robust 
>> solution, but a little slower and heavier, it to have an 
>> update_notification that manually POSTs to _replicate?
> We're committed to making continuous replication as robust and 
> performant as possible.  The entire replication codebase went through a 
> significant refactoring after 0.9, and what you're seeing is us ironing 
> out a few of the kinks before 0.10 gets out the door.  I'd encourage you 
> to give "continuous":true a shot, provided my answer to 2) isn't a 
> deal-breaker.

No, 2) isn't a deal breaker.

>> Will there be a way to manage the list of replicant databases when the 
>> persistent continuous replication feature is complete?
> Absolutely yes.  It will probably be a special DB called _replication 
> where you can PUT and DELETE documents that configure continuous 
> replications.

That's great.

Is there a wiki or place that CouchDB keeps its design documents for new 
features for people to learn about, e.g. a ticket or checked into svn as a text 

>> 3) How does continuous replication deal with network outages, say if a 
>> link goes down between the Los Angeles and Bristol data centers?  Does 
>> CouchDB deal with a hanging TCP connection ok?
> CouchDB retries requests using a timeout that doubles with every 
> failure.  It does this for about 5 minutes, then gives up.

That sounds like it would still then require an external script to start the 
replication again.

In fact, our Bristol office had a power outage earlier today that lasted over an 
hour, so to write a script to kick start replication again would be inconvenient.

>> 5) I wrote the following Bourne shell script and after running it for 
>> an hour, it consumes 100% of a CPU.  This is even after stopping the 
>> shell script and compacting both databases.  What would explain this 
>> behavior?
> I couldn't quite get that script to work ($HOST2 was undefined, and then 
> something else failed), but can you try it again with a fresh checkout?  
> I fixed a bug last night that could very well have caused this.  Best,

I've attached the latest version of the script which I just ran.

After multiple runs of the script and letting it run indefinitely, I've noticed 
that something will fail in CouchDB and the script will either wait forever for 
the key to appear in the other database or a PUT will fail.

The last error I got was that using curl and PUT returned nothing and this error 
in my shell.  It scrolled past the top, so I don't have the top of the stack:

** Reason for termination ==
** changes_loop_died
[error] [<0.144.2060>] {error_report,<0.23.0>,
[error] [<0.160.2060>] ** Generic server <0.160.2060> terminating
** Last message in was {'EXIT',<0.144.2060>,changes_loop_died}
** When Server state == {state,<0.161.2060>,nil,
** Reason for termination ==
** changes_loop_died


View raw message