couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: replication problems
Date Thu, 11 Oct 2012 15:37:02 GMT
With the caveat that we don't "need" id stability, yes. It's highly
desirable that we can find a checkpoint if one exists, though.
Consider a 3 node bigcouch cluster. Depending in which node handles
the replication, you'll get a different rep id, and therefore look for
a different checkpoint doc. if all 3 nodes would generate the same rep
id for a task, the checkpoint doc will always be found, since each
node can find any document in the database, even if its held remotely.
The dynamic port case from the ticket is another way to see that we
can have a checkpoint miss despite there being a perfectly good

I'd like to hear more on the API approach as I can't see how it would
work, or at least not work better than the proposal for each node to
generate a uuid, report it in the welcome message, and create a
generation 3 rep id algo that would fetch the uuid and substitute it
for the unstable host:port values.

One other thought occurs, if the port is equal to 5984, we can assume
its stable and not do the GET / to find the uuid. Perhaps a port
whitelist for folks to move to 80 or 443 too.

Sent from the ocean floor

On 11 Oct 2012, at 15:18, Dave Cottlehuber <> wrote:

> On 11 October 2012 15:58, Bob Dionne <> wrote:
>> Incorporating a unique id from the source and target seems like a good way to go
but I'm wondering if an id from an ini file will
>> work in the clustered BigCouch case. Would an API level request work better? Something
the replicator would interrogate
>> for both the source and the target.
> Making sure I understand the problem here:
> For couches that may not have a fixed IP/DNS/port combination, we need
> a sticky way of identifying replication endpoints, right.
> The API approach makes sense, perhaps something you get back in GET / ?
> I think this won't work however for anybody with a round-robin DNS or
> loadbalancer in front a multiple (possibly geographically spread)
> clusters (whether BC or normal couch). Not sure how common a scenario
> this is though.
> A+
> Dave

View raw message