couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Marshall <>
Subject Re: replication
Date Mon, 11 Apr 2011 16:37:48 GMT
On 04/10/2011 08:59 AM, Mage wrote:

> As far as I understand I have to setup 3 * 2 replication ways (push and
> pull from A to B, A to C and b to C). I need realtime sync (continous
> replication?).


> The real goal is that if node C goes down, for example because of
> network error, 

IIRC network errors won't kill replication -- it will merely keep trying
until the connection is re-established and then come back into sync. But
I could be wrong here...

> then it comes up I'd like to be sure it starts synching
> again in all ways (like it did before the error) without manual
> interference.

This is targeted for release in version 1.2, I believe.

Unfortunately for now CouchDB will not "remember" your replication; you
will instead need some out of band process to get everything set the way
you want.

> It would be also good to be able to restart node C (or B
> or A) and have it working again without doing anything on the other
> nodes (A and B). I prefer configuration over crontab jobs

If I was correct above, you should be able to restart node C and merely
re-establish replication on it -- nodes B & A would eventually try to
replicate and succeed.

> Getting e-mail about conflicts would be also vital for a web app.

Are you *sure*? Think very carefully here.

IMO, conflicts should not be seen as "bad". Instead, they should be seen
as an intermediate state that should be resolved as soon as possible.

If you design your app to watch for _conflicts: true, and handle the
conflicts in a way that makes sense to your application, you will be
much happier -- not only will your application "just work" without your
pager vibrating 24x7, but you may find that your app will be able to do
things you hadn't thought of before.

Owen Marshall
FacilityONE | (502) 805-2126

View raw message