couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Polzer <>
Subject Re: Peer-to-Peer Replication
Date Wed, 06 Apr 2011 20:32:43 GMT


On 06.04.2011, at 22:24, Zdravko Gligic wrote:

>> *You* make the graph -- not CouchDB!
> Given a large number of peers, could this not be a daunting task - to
> ensure that everyone gets eventually updated in a relatively efficient
> and timely manner?
>> CouchDB will follow your instructions. No more or no less.
> Am I correct in my interpretation of documentation that regardless of
> the overall design, replication is always between 2 nodes - a source
> and a target? In other words there is no way to throw at CouchDB
> multile nodes as sources and/or destinations and it would magically
> keep them all updated.

I am now quoting from my soon to be finished thesis (yay! :-) ):
Replication in CouchDB can be configured in multiple ways:
* Replication can be pushed or pulled. This is very handy for replication of mobile databases,
where no fixed IP can be provided and the telecommunication providers may prohibit the use
of dynamic DNS. Replication can just happen by pushing it towards other nodes.
* Replication can be configured for Master-Slave or Peer-to-Peer.
* Replication can be configured for continuous replication or just be one-time triggered by
the application if needed. Until version 1.2 of CouchDB is released, replication settings
are lost upon restarting CouchDB.
* Databases within one CouchDB can be replicated. This might be useful to keep a copy of a
database on another hard-drive within one CouchDB node.
* Replication can be filtered so not all information is replication. 
* Documents can be named for replication.

I agree on the thaught 
 "to throw at CouchDB multile nodes as sources and/or destinations and it would magically
keep them all updated."

There is a feature coming for CouchDB with 1.2 that includes a dedicated document (or database?)
about replication settings. It would be nice to be able to replicate that one as well...

>> CouchDB doesn't ensure that the latest revision wins -- you are expected
>> to resolve conflicts in a way that makes sense for your application.
> I understand this in context of revisions to a single document.
> However, I was more curious about how it internally determined which
> of 2 arbitrary peers had a more recent and up to date copy.

> Thanks again.

View raw message