couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Smith (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1259) Replication ID is not stable if local server has a dynamic port number
Date Wed, 24 Aug 2011 01:49:29 GMT

    [ 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

        

Mime
View raw message