Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1278)
Subject: Re: Replicating with two CouchDBs that share the same URL
From: Robert Newson <rnewson@apache.org>
In-Reply-To: 
 <CALbocOk1jWE3Mm9zVktCBV2uYJx8bSNYDd0hPa4y38XWUHdNkA@mail.gmail.com>
Date: Sat, 11 Aug 2012 16:52:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D5808491-CBCE-406F-A773-349122868E3A@apache.org>
References: 
 <CALbocOkbJxohEsgfNwyuobCmkKkz+QLaw9oYzwqj8M1pKqt_9Q@mail.gmail.com>
 <CALbocOk1jWE3Mm9zVktCBV2uYJx8bSNYDd0hPa4y38XWUHdNkA@mail.gmail.com>
To: user@couchdb.apache.org


The replicator searches for a checkpoint document on source and target =
when it starts. This document identifies the update_seq that the =
previous replication had reached. The checkpoint document's id is =
derived from the source hostname:port and target hostname:port (plus =
some other properties).

B.


On 11 Aug 2012, at 14:38, Ladislav Thon wrote:

> Friendly ping? :-)
>=20
> LT
>=20
> 2012/6/27 Ladislav Thon <ladicek@gmail.com>
>=20
>> Hi,
>>=20
>> we're using CouchDB (version 1.1.1 currently, but planning to upgrade =
to
>> 1.2.0) because of its multi-master replication. The replication =
topology is
>> a simple star -- single central server and a number of clients that
>> replicate both from and to the central server. Writes are (almost) =
always
>> done on the clients.
>>=20
>> Now for high availability, the central server isn't actually a single
>> machine, but two machines (and therefore two couches) whose IP =
addresses
>> are mapped to the same domain name (DNS round robin). These two =
couches
>> also replicate with each other. The clients don't know about this, =
they
>> always replicate from and to https://central.couch:6984/database.
>>=20
>> This might not be the best architecture for HA and we would be able =
to
>> change it, but I'd still love to get an answer to this question: is =
CouchDB
>> able to cope with this? How does it know that it replicates with the =
same
>> couch it replicated with before (so that it only has to replay =
changes) and
>> how does it recognize that it replicates with a different couch than =
before
>> (and has to copy the whole database)?
>>=20
>> I know that it was already proposed several times to add an UUID to
>> CouchDB server/database, which would solve this issue, and I also =
know that
>> it's very easy to end up with duplicates, which renders universallly
>> unique identifiers ... not so *unique* (i.e. useless).
>>=20
>> ---
>>=20
>> Also, I have a question about replication monitoring. Are there some =
best
>> practices for monitoring whether the replication is working? I can of
>> course read the corresponding document in the _replicator database =
and look
>> at the _replication_state field, but this will only tell me that the
>> replication is *running* -- and I want to know that it's actually =
*working
>> *. For now, we are using a pretty naive approach: 1. Every 10 =
minutes,
>> write a document with current date and time to the central couch. 2.
>> Periodically check on all clients (we have them under control) that =
the
>> document isn't too old. Is there a better approach?
>>=20
>> Thanks for your opinions!
>>=20
>> LT
>>=20