incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Dionne <dio...@dionne-associates.com>
Subject Re: Simple load-balancing replication best practices
Date Sun, 07 Oct 2012 12:48:02 GMT
https://github.com/cloudant/couch_replicator/commit/7feec1bd998264dd8

sorry, I should wait until I've had coffee :)

On Oct 7, 2012, at 8:32 AM, Octavian Damiean <mainerror@gmail.com> wrote:

> I'd be interested to read that if you insert the URL too Bob. :)
> 
> On Sun, Oct 7, 2012 at 2:22 PM, Bob Dionne <dionne@dionne-associates.com>wrote:
> 
>> There used to be an advantage to using PULL but that's no longer the case.
>> 
>> However PULL replications are a bit more stable when attachments are
>> involved, so I'd recommend them over PUSH. I've described the problem
>> here[1] in BigCouch if you're interested in the details.
>> 
>> On Oct 7, 2012, at 5:04 AM, Nick North <north.n@gmail.com> wrote:
>> 
>>> I'm also interested in whether there is a preference for push or pull
>> with
>>> CouchDb 1.2. I have a full-mesh replication setup using pull replication,
>>> but have no idea whether push might be better in some way. Is there a
>>> replication guru out there who could enlighten us?
>>> Nick
>>> On 4 October 2012 17:48, Dave Cottlehuber <dch@jsonified.com> wrote:
>>> 
>>>> On 4 October 2012 17:04, Steve Koppelman <steve.koppelman@gmail.com>
>>>> wrote:
>>>>> Assuming a hubless (i.e. not master-slave) set of 4 couchdb 1.2.0
>>>>> servers behind a load balancer, is there a recommended best-practice
>>>>> for setting up the replication relationships? I'm most interested in:
>>>>> 
>>>>> * Assuming the _replicator document is on one of the two nodes in a
>>>>> relationship, is there a preference for push vs. pull replication
>>>>> relationships? I seem to recall pull as being regarded as more
>>>>> reliable than push through 1.1.1.
>>>> 
>>>> Hope somebody else comments on this, I'm interested to know if this
>>>> still makes a difference.
>>>> 
>>>> 
>>>> 
>> 
>> 


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