couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randall Leeds (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-782) Restarting replication
Date Thu, 03 Jun 2010 17:31:01 GMT

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

Randall Leeds commented on COUCHDB-782:
---------------------------------------

Damien, I originally reasoned that this was a good thing because the identity of a database
would follow the database itself. I now realize that while this is great for moving dbs it's
a disaster for copying them because you create two (possibly diverging) instances which claim
to be the same.

Regarding a canonical format, how does this simple idea sound:
Generate a random uuid on the #db record, but do not write it out in the header. This way,
dbs have a new uuid every time they're opened. Then, the replicator can try to open the bare
db name at the end of the URI locally and compare that to the uuid returned from the http
info. Then, local dbs can be detected and canonicalized to the bare db name without relying
on hostname information that is sensitive to system/dns configuration problems.

As a side bonus, replicating a database to itself could *always* be detected at the outset,
which reduces the checkpoint conflict scenarios to only ones in which a previous checkpoint
save succeeded but the client timed out waiting for the reply, at which point replication
should safely restart gracefully. I'm happy to put this together later.

> Restarting replication 
> -----------------------
>
>                 Key: COUCHDB-782
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-782
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Replication
>    Affects Versions: 0.10
>         Environment: Ubuntu, 9.10
>            Reporter: Till Klampaeckel
>
> So we had to restart replication on a server and here's something I noticed.
> At first I restarted the replication via the following command from localhost:
> curl -X POST -d '{"source":"http://localhost:5984/foo", "target":"http://remote:5984/foo"}'
http://localhost:5984/_replicate
> In response, futon stats:
> W Processed source update #176841152
> That part is great.
> Last night I did not have immediate access to the shell so I restarted replication from
remote (through curl on my mobile):
> curl -X POST -d '{"source":"http://user:pass@public.host:5984/foo", "target":"http://remote:5984/foo"}'
http://user:pass@pubic.host:5984/_replicate
> The response in futon this morning:
> W Processed source update #1066
> ... and it kept sitting there like it was stalled and only continued in smaller increments.
> I restarted CouchDB and restarted from localhost - instant jump to 176 million.
> I'm just wondering what might be different accept for that one is against the public
interface, vs. localhost. I'd assume that replication behaves the same regardless.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message