Hey, Do you mean you want 180 instances replicating into the central DB? Why not have the remote instances push replicate? Then they all just need to know what the URL of the central instance is. As Jens has just said, setting that up as a continuous replication, and using the _replicator db will mean your remote instances should sync up asap.
If you have docs being created on the remote nodes you could have your app record the username, machine name or some other id and a timestamp when writing a doc, then you can generate a view to see when the last document from a user/machine appeared. You need to be a bit careful, though. The question "who hasn't replicated into the central DB" can be a bit meaningless as there might be a good reason that an instance hasn't replicated yet (e.g. the guy's offline for a while), so tread with care. You don't want to put locking into the system, so you need to design for asynchronous, distributed updates. Cheers Simon On Tuesday, 5 June 2012 at 22:15, Gabriel Mancini de Campos wrote: > Hi Guys, > > I'm new in the list, > I have working on a project how will use the power of the replication of the > couchdb. > I have learn about this incredable nosql db, and it's a amazing pice of > software. > I have a doubt and i will share with you guys. > this is the senario, > 180 Distributers, each one with your couchdb installed and 1 load-balance > couchdb in amazonws. > this 180 Distributers not have an static IP, because this i will need put the > json config replication in them. > How i know, who not replicate with the amazonws-couch? > > please help > > thanks (sorry about my english) :-)
