Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 98084 invoked from network); 6 Apr 2011 19:01:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 6 Apr 2011 19:01:14 -0000 Received: (qmail 52661 invoked by uid 500); 6 Apr 2011 19:01:12 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 52622 invoked by uid 500); 6 Apr 2011 19:01:12 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 52614 invoked by uid 99); 6 Apr 2011 19:01:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Apr 2011 19:01:12 +0000 X-ASF-Spam-Status: No, hits=2.9 required=5.0 tests=FREEMAIL_FROM,FS_REPLICA,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of email.workbench@gmail.com designates 209.85.161.52 as permitted sender) Received: from [209.85.161.52] (HELO mail-fx0-f52.google.com) (209.85.161.52) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Apr 2011 19:01:06 +0000 Received: by fxm6 with SMTP id 6so2070502fxm.11 for ; Wed, 06 Apr 2011 12:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=SITf6TlugadSZz9gvCHgphRs5c+NtC525hMRL/LMmEk=; b=Bg16CGFfuWUDrLNBA/yizGHhUeZvIVeDzL9GzrP8D2Y5I0M6YGNo6+Op379IUjeCJt q/Ae+bpFBqC8LrzvUNKeD/Dvv+Tv+CehDCdOuCvotneRCuBeLdk8p/nCowSAwZWULTCi INVcLp/wrqMQIhE+rgxwiedWQ1fRaRvnk/8co= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=jF7yKVlSHOcx3HgYo1uWHNyJIjh3ZEx/2+tpnb9e6GhWcJ/XHx2P3IVasz77ZbL4st SHXcaVwv3nAzh7vPd0FBDNkqrG5TUep4ZtSSWjZAhIUfJphxlWqr1ThfnNh3KyueF5jq lKtV8aapIkNd3/J42aAora8CzuEG1vSZYisqQ= MIME-Version: 1.0 Received: by 10.223.27.129 with SMTP id i1mr1257609fac.24.1302116444832; Wed, 06 Apr 2011 12:00:44 -0700 (PDT) Sender: email.workbench@gmail.com Received: by 10.223.121.82 with HTTP; Wed, 6 Apr 2011 12:00:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Apr 2011 15:00:44 -0400 X-Google-Sender-Auth: boV8e6-QSjMdyyg-uFCrI_Rw75k Message-ID: Subject: Re: Peer-to-Peer Replication From: Zdravko Gligic To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 >>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? >>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. Thanks Nebu.