couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Marshall <omarsh...@facilityone.com>
Subject Re: replication
Date Mon, 11 Apr 2011 17:43:22 GMT
On 04/11/2011 01:19 PM, Mage wrote:

> On 04/11/2011 06:37 PM, Owen Marshall wrote:
>>
>> IIRC network errors won't kill replication -- it will merely keep trying
>> until the connection is re-established and then come back into sync. But
>> I could be wrong here...
> I pulled out the ethernet cable from the laptop for about 5 minutes then
> plugged back and continous replication didn't get restored.
> 
> However calling some cronjob once per minute seems to be acceptable.
> Until a new vesion comes out with permanent replication feature.

I guess I was wrong. Strange -- I was pretty sure that I was right. I
haven't poked the replication in a while, but it is possible that
retries back off when replication fails. Hopefully someone more
knowledgeable can expand on this.

>> Are you *sure*? Think very carefully here.
>>
>> IMO, conflicts should not be seen as "bad". Instead, they should be seen
>> as an intermediate state that should be resolved as soon as possible.
>>
>> If you design your app to watch for _conflicts: true, and handle the
>> conflicts in a way that makes sense to your application, you will be
>> much happier -- not only will your application "just work" without your
>> pager vibrating 24x7, but you may find that your app will be able to do
>> things you hadn't thought of before.
> In the meantime I played a bit with CouchDB and realized that conflicts
> happen when: I start working with a document on node A => I modify and
> save the same document on node B => Replication happens => I try to save
> the original object on node A.
> 
> So conflict can happen not during the replication but on save if I am right.

Conflicts will occur any time that edits diverge. It's possible for
conflicts to occur on replication:

* Nodes B & C pull document 1 from node A
* Nodes B & C make & save separate changes to document 1
* Replication occurs, either between B & C, or from one node to A and
then to the other.

Note that continuous replication reduces the time window for conflicts
to occur, but it will not eliminate them. Thus you must treat conflicts
not as an "exceptional case" but as an expected state.

> The strange thing is, at least for me, that if I modify a document on
> node A *when there is no replication* for example if the link is dead
> then I modify the same document on node B and after that I start
> replication then the later version of the document wins and the other
> version becomes "lost" without any trace. It doesn't even stays there as
> previous version. At least as I experienced so far. I might missed
> something.

A basic `GET /db/document` will not provide any indication that a
conflict has occurred. It's up to you to ask.

See here for more:
http://wiki.apache.org/couchdb/Replication_and_conflicts

-- 
Owen Marshall
FacilityONE
omarshall@facilityone.com | (502) 805-2126


Mime
View raw message