Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of omarshall@facilityone.com
 designates 216.135.43.146 as permitted sender)
Message-ID: <4D9CBEEB.3090102@facilityone.com>
Date: Wed, 06 Apr 2011 15:28:43 -0400
From: Owen Marshall <omarshall@facilityone.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US;
 rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: user@couchdb.apache.org
CC: Zdravko Gligic <zgligic@gmail.com>
Subject: Re: Peer-to-Peer Replication
References: <BANLkTi=8cOLhFLdumUPoG72EFCWPHWLzcw@mail.gmail.com>
 <BANLkTinv_UrZt8QMDRf19yZ_1JZtHcVR9g@mail.gmail.com>
In-Reply-To: <BANLkTinv_UrZt8QMDRf19yZ_1JZtHcVR9g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 04/06/2011 03:00 PM, Zdravko Gligic wrote:
>> The replication model is such that for every connected graph of peers, all peers in that graph
>> will update to the same up-to-date state. This is what they call
>> "eventual consistentcy".
> 
> Replication documentation seems to talk about replication between 2
> nodes (a source and a target) with 2 specific URSs and not any magical
> "graph of peers".  However, if there is such magic then where do I
> find some more info?

*You* make the graph -- not CouchDB!

Say you would like to place the same database on five CouchDB nodes. You
are free to decide how you want those nodes connected (or not).

For example, you could:
* set up a star network and make every node replicate from N1.
* set up a mesh, partially *or* fully connected
* continuously replicate on some nodes and replicate on demand on others

CouchDB will follow your instructions. No more or no less.

>> It's like in bittorrent, you don't have to worry about the clients with full copies of the
>> file somehow losing data; the replication data is versionned, so your
>> peers will only replicate
>> "forward" in time, not backwards.
> 
> I did find and read some info on how CouchDB keeps 2 indices, one by
> doc ID and a second being a numeric sequence that is specifically for
> replication purposes.  Since these are local sequences, I am a bit
> curious how it determines which one is later (as higher numbered one
> could be older?) but since I am painting by numbers here, I can let go
> of that curiosity and simply assume that it magically happens.

CouchDB doesn't ensure that the latest revision wins -- you are expected
to resolve conflicts in a way that makes sense for your application.

It will ensure that the *same* revision is *always* displayed as the
winner across all peers.

-- 
Owen Marshall
FacilityONE
omarshall@facilityone.com | (502) 805-2126