Thanks for the warm welcome. It's really great that all this functionality is in the database from the get go. I've got couchdb running on a couple of machines now and testing how it performs.
I should explain what I'm trying to do. I'm looking at having 1-2 master couchdb servers(use continuous replication here) and then have multiple(100 or so) client couchdb connecting up and doing a pull replication. The client database would serve a local application (even if the client isn't on the net). I was thinking I can do a push replication from the clients to the server to update. From what has been said it looks like it would work. Think I will need to be careful with the id fields. http://johnpwood.net/2009/06/30/couchdb-databases-and-documents/ suggests that couchdb generated keys won't work well and I think it won't in my case. As an alternative I can keep the client databases as read only and would store the updates in a separate xml file or something. Update when I know internet is available. It will ensure that no conflicts can happen between the clients and servers. Back to figuring out why replication fails when using nginx and couchdb as a subdirectory. Thanks again Antoine On Tue, Oct 26, 2010 at 8:31 PM, Randall Leeds <[email protected]> wrote: > On Tue, Oct 26, 2010 at 11:52, Dave Cottlehuber <[email protected]> wrote: >> On 27 October 2010 03:50, Antoine Kurukchi <[email protected]> wrote: >>> Hi All, >>> >>> Been reading a lot about couchdb and am really impressed by it. Great >>> work. I have got a few questions about replication and new documents. >> >> Welcome aboard the couch, Antoine. >> >>> A lot is mentioned about continuous replication and bidirectional >>> replication but is it possible to have both features working at the >>> same time? If it is possible, what happens if there is a disconnection >>> between the two database servers and are there any pit falls with this >>> approach? > > Bi-directional replication isn't really a "thing" in CouchDB. There's > been mention recently of adding API sugar to make it easy, but it's > just two replications. Whether they are continuous or not is > irrelevant. > >> >> I've had continuous replication running for some time on a small 3-way >> replicated couch without any issues, in a multi-master mesh (mmm). I >> believe there may be a timeout - can anybody confirm? > > For pull replication, there is no timeout on the source. The source > will stream changes to the target with empty lines every ten seconds > as a heartbeat. If the target misses 3 of these it will give up. So > you have 30 seconds of disconnection before a continuous pull will > fail. The command to start continuous replication is idempotent, > though, so it's easy to set up a job that ensures it's always running > by triggering it every minute or so. In the next release there should > be a way to tell CouchDB about persistent replication jobs that should > always be running. > > For push replication there is no longpoll on the database changes. > Instead, you'll only see a failure if one of the individual requests > totally fails (10 times, with exponential backoff, I think it comes > out to around 10-15 minutes of disconnection before it'll die). > > Looks like Dave answered the rest of your questions. Welcome aboard. >
