Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Subject: Re: Peer-to-Peer Replication
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Christian Polzer <chris@hai-fai.de>
In-Reply-To: <BANLkTik=XghzGMgE7EiVg8Cbxt+6rEQBjg@mail.gmail.com>
Date: Wed, 6 Apr 2011 20:24:04 +0200
Cc: Zdravko Gligic <zgligic@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7D74108-937C-4334-B601-F89EC77CA533@hai-fai.de>
References: <BANLkTi=8cOLhFLdumUPoG72EFCWPHWLzcw@mail.gmail.com>
 <BANLkTik=XghzGMgE7EiVg8Cbxt+6rEQBjg@mail.gmail.com>
To: user@couchdb.apache.org

I would suggest reading this:

http://guide.couchdb.org/draft/replication.html

1.) It is a key feature to CouchDB not to rely on centralized =
(master-slave) replication, but you could build it with CouchDB
     Peer-To-Peer by definition does exclude centralized servers (well, =
I think).
2.) I think if two CouchDB's cover each other, replication should work =
as well, as there is just the same port in use for everything.

Regards,
Chris


On 06.04.2011, at 20:13, Zdravko Gligic wrote:

> OK, lets start with some basic questions ;)
>=20
> (1) How would two CouchDB go about discovering and meeting each other?
> Would this not require a central server (similar to IRC) and are
> there any hosted solutions?
>=20
> (2) Once at least two CouchDB's discover and meet each other, is it
> just their URLs (domain name or IP based) that are needed? What about
> routers and/or firewalls?
>=20
> Thanks again.
>=20
>=20
> On Tue, Apr 5, 2011 at 1:36 PM, Zdravko Gligic <zgligic@gmail.com> =
wrote:
>> Hi Folks,
>>=20
>> Are there any large implementations of CouchDB peer-to-peer
>> replications or even smaller open source samples?  Actually, the =
piece
>> that I am mostly interested in is at the application/design end of =
how
>> to go about implementing the "traffic cop" for a use case where
>> everyone is eventually synchronized with everyone else.
>>=20
>> Given a large number of peers that one could replicate to/from, is
>> there anything within CouchDB that can be "posted centrally" to know
>> how up to date anyone is, so that badly out of date peers are
>> replicate to/from the more up to date ones, instead to/from each
>> other?  What else should I ask, if I knew better ;?)
>>=20
>> Thanks,
>> Zdravko
>>=20