couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filipe Manana (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1341) calculate replication id using only db name in remote case
Date Wed, 16 Nov 2011 11:16:51 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151140#comment-13151140
] 

Filipe Manana commented on COUCHDB-1341:
----------------------------------------

Hi Bob, that's definitely an issue.

However I think that are 2 issues by using this approach of considering only the remote db
name and excluding the server/port component of the URL.

Imagine that on a CouchDB instance you trigger these 2 replications:

(replication 1)
{
    "source": "http://server1.com/foo",
    "target": "bar"
}

(replication 2)
{
    "source": "http://server2.com/foo",
    "target": "bar"
}

>From what I understand, both will have the same replication ID with this patch, right?
If so you can't have both replications running in parallel, one of them will have conflict
error when updating its checkpoint local doc (because it's the same for both).

Also, if you start replication 1, followed by replication 2 and then followed by replication
1 again, we can lose the benefits of the checkpointing.
Suppose you start replication 1, after it finishes the checkpoint document's most recent history
entry has source sequence 1 000 000.
Then you start replication 2. Because the ID is the same as replication 1, it will overwrite
the checkpoint document. If it checkpoints more than 50 times (the maximum history length),
all checkpoint entries from replication 1 are gone. When it finishes, if you start replication
1 again, it will no longer find entries in the checkpoint history related to it, so the replication
will start from sequence 0 instead of 1 000 000.

Basically, if we have a source or target like "http://user:password@server.com/dbname", I
think we should consider everything from the URL except the password (eventually the protocol
as well).
                
> calculate replication id using only db name in remote case
> ----------------------------------------------------------
>
>                 Key: COUCHDB-1341
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1341
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Replication
>            Reporter: Bob Dionne
>            Assignee: Bob Dionne
>            Priority: Minor
>
> currently if the source or target in a replication spec contains user/pwd information
it gets encoded in the id which can cause restarts if the password changes. Change it to use
just the db name as the local case does, Here's a draft[1] of a solution.
> [1] https://github.com/bdionne/couchdb/compare/master...9767-fix-repl-id

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message