[
https://issues.apache.org/jira/browse/COUCHDB-1259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13089939#comment-13089939
]
Jason Smith commented on COUCHDB-1259:
--------------------------------------
The small problem with Damien's suggestion is that, presently, the client (and
the replicator) hasn't enough information to produce a good replication ID.
Randall, I'm not sure I understand what is bad about sysadmins copying files.
Shouldn't that be *exactly* the situation where the replicator notices that it
can skip some changes?
If a sysadmin runs (and then restarts couch!)
mv old.couch new.couch
or perhaps
rsync user@somewhere:/path/to/remote.couch ./new.couch
and runs a replication, it would be nice for it to continue where it left off.
Does that already happen? I think the answer is no: the replication ID depends
on the database name. A server ID doesn't help to detect database renames. A DB
rename is a URL "rename," no different from changing the port.
Is it possible to address both bugs at the same time? Can the client
(replicator) compute a stable replication ID, without any help from core
CouchDB?
In other discussions, Adam mentioned possibly demoting _security to be merely a
cache of a _local/security doc (and promoting _local docs to have revision
trees).
Could the client (replicator) or perhaps Couch create e.g. _local/metadata with
a UUID? To calculate the replication ID, check for _local/metadata, and if not
available then fall back to the URL, database name, etc. I think that would
require no changes to core CouchDB, just the replicator application. And
clients (the one creating /_replicator docs) needn't change.
> Replication ID is not stable if local server has a dynamic port number
> ----------------------------------------------------------------------
>
> Key: COUCHDB-1259
> URL: https://issues.apache.org/jira/browse/COUCHDB-1259
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
> Affects Versions: 1.1
> Reporter: Jens Alfke
>
> I noticed that when Couchbase Mobile running on iOS replicates to/from a
> remote server (on iriscouch in this case), the replication has to fetch the
> full _changes feed every time it starts. Filipe helped me track down the
> problem -- the replication ID is coming out different every time. The reason
> for this is that the local port number, which is one of the inputs to the
> hash that generates the replication ID, is randomly assigned by the OS. (I.e.
> it uses a port number of 0 when opening its listener socket.) This is because
> there could be multiple apps using Couchbase Mobile running on the same
> device and we can't have their ports colliding.
> The underlying problem is that CouchDB is attempting to generate a unique ID
> for a particular pair of {source, destination} databases, but it's basing it
> on attributes that aren't fundamental to the database and can change, like
> the hostname or port number.
> One solution, proposed by Filipe and me, is to assign each database (or each
> server?) a random UUID when it's created, and use that to generate
> replication IDs.
> Another solution, proposed by Damien, is to have CouchDB let the client work
> out the replication ID on its own, and set it as a property in the
> replication document (or the JSON body of a _replicate request.) This is even
> more flexible and will handle tricky scenarios like full P2P replication
> where there may be no low-level way to uniquely identify the remote database
> being synced with.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
