incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale Harvey <d...@arandomurl.com>
Subject Re: Handle the Welcome Request
Date Tue, 15 Apr 2014 18:12:08 GMT
Yup as far as the implementation thats right,
https://github.com/apache/couchdb/blob/master/src/couch_replicator/src/couch_replicator_utils.erl#L62

Saying its useless is wrong though, if you do a file based replication the
databases should have the same uuid, it does in the pouch implementation at
least, the entire point is that a host does not map to a database, its data
does.

Pouch uses a get on / to fetch the uuid, it will use the host if that
request fails, that just means < 1.3 couchdb's and ones that plays around
with / will fallback and more likely to do redundant replications in the
case of a changed host.

Theres a related post on the replication mailing list
http://mail-archives.apache.org/mod_mbox/couchdb-replication/201404.mbox/browserin
which I think having per db uuid's would be beneficial for multiple
reasons


On 15 April 2014 18:50, Alexander Shorin <kxepal@gmail.com> wrote:

> On Tue, Apr 15, 2014 at 9:29 PM, Jens Alfke <jens@couchbase.com> wrote:
> > On Apr 14, 2014, at 11:50 PM, Alexander Shorin <kxepal@gmail.com> wrote:
> >
> >> Not, it wouldn't. The replicator doesn't request source or target UUID
> >> via API, but takes the value from server which runs the replication.
> >
> > No, I meant the _remote_ server’s UUID. The only way to get that is to
> send a "GET /" request.
> >
> > Anyway, I’m trying to verify this but not seeing it right now. I’m
> seeing CouchDB send a HEAD /dbname and then a GET /dbname [which seem
> redundant!] but not the GET /. Pretty sure I’ve seen this in the past,
> though, and it does seem the only way for the replicator to get the UUID,
> which is used to construct the checkpoint ID (right?)
>
> No, there wasn't ever used GET / request in CouchDB replication.
> Server UUID was introduced in 1.3 release: before it pair (host,port)
> was used and since that time no changes were made for that process.
> The remote server UUID usage is a little useless, since replication ID
> for protocol version 3 between two remote servers is based on next
> structure: {LocalUUID, {remote, SrcURL, Headers}, {remote, TgtURL,
> Headers}}. If you replace LocalUUID with any remote server's UUID
> value this would change nothing, but will cost you one additional
> request, losing portability since pre-1.3 releases has no UUID value
> and replication startover in case when remote database will be
> migrated to the another instance with the same URL (some
> proxy/balancer in front of remote instance is the common case).
>
> --
> ,,,^..^,,,
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message