Hi Blair, all good questions, I'll try to answer inline:
On Aug 25, 2009, at 5:10 PM, Blair Zajac wrote:
> Hello,
>
> We're looking at using CouchDB's replication to allow us to easily
> have multi-master replicating databases across multiple facilities,
> (e.g. Los Angeles, Albuquerque, Bristol, England, etc). It looks
> like it'll be the perfect tool for the job.
>
> Some questions on the current implementation and the work that I've
> read is going to be in forthcoming releases.
>
> 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.
> 2) With the persistent continuous replication feature, is there a
> way to stop continuous replication without restarting couchdb?
At the moment, no. We just didn't have time to add that feature to
0.10. It's coming soon, though.
> 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.
> 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.
> 4) It would be nice for CouchDB to have in it a list of replicant
> databases that it will automatically push changes to, so this list
> could also be maintained in CouchDB, instead of with an external
> script. Is there any work on a feature like this? This could be
> easily done with an external update_notification script.
Yep, definitely planned for the near future (certainly by 0.11).
> 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,
Adam
|