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 checkpoint.
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 <[email protected]> wrote: > On 11 October 2012 15:58, Bob Dionne <[email protected]> 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
