incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Documentation: 1. Order in which replication is executed 2. Single invocation multiple ports 3. Replication bound to a
Date Fri, 11 Dec 2009 20:44:29 GMT
On Fri, Dec 11, 2009 at 3:34 PM, Ceriel Jacobs <cerieljacobs@gmail.com> wrote:
> Dear list,
>
> 1. Quote from the documentation: [1]
>> "... for each updated document, only fields and blobs that have changed are replicated...
If replication > fails... the next replication restarts at the same document where it left
off"
>
> My question is: "How is the order of replication?"
> In other words: "In which order are things in a CouchDB replicated?"
>
> For instance:
> * 1st most recent changes, 2nd older changes, 3th oldest changes
> and/or
> * 1st inserts, 2nd updates, 3th deletes
> and/or
> * 1st data, 2nd BLOB's
> and/or
> * 1st documents in the top of the tree, 2nd are documents in the second level of the
tree, etc.
> and/or
> * 1st walking down a tree till its leave, then the next leave of the same parent, until
the last, and then one level up
>
> Any information that clarify the inner workings is welcome.
> Especially in situations with mixed data and BLOB's.
>
> In case BLOB's are replicated with identical priority as stored data, that could lead
to a design decision where BLOB's will not be stored in CouchDB though on the file system
level. This to ensure that textual content is replicated with highest priority.

The general order is by update_seq:

$ curl http://127.0.0.1:5984/db_name/_all_docs_by_seq

I'm not sure on what happens right at the point of sending docs, but
replication should be initiated in roughly that order. There may be
details that affect two documents right next to each other (due to
simultaneous transers).

Depending on replication direction, the attachments are also
replicated differently. I can't ever keep it straight, but one
direction they get replicated inline (for the time being) and the
other direction they're replicated OOB. But the general order in which
that happens is based on the update_seq as well.

> 2. A related question is if a single invocation of CouchDB can be bound to multiple ports?

No.

> 3. In case this is possible, can replication then be bound to run on a specific port?
> This would give the ability to limit the bandwidth of replication traffic with a firewall
rule. And not reduce the speed other (CouchDB) network traffic.

If it were possible, then you'd just specify the port in the URL
passed to the replicator.

HTH,
Paul Davis

Mime
View raw message