You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@couchdb.apache.org by Simon Temple <si...@amalto.com> on 2017/04/11 08:45:10 UTC

How scalable is replication?

I'm searching for information about replication scalability, has anyone deployed replication across hundreds or even thousands of instances?

Can I realistically expect a single cluster to act as a replication point for a thousand replicas?

The database I wish to replicate contains user information.  This information is not updated very frequently but is read often. <http://bit.ly/1Lqt8qy>

TIA

Simon
 <http://bit.ly/1Lqt8qy>
 <http://bit.ly/1Lqt8qy> <http://bit.ly/1Lqt8qy>

Re: How scalable is replication?

Posted by Stefan Klein <st...@gmail.com>.

2017-04-11 10:45 GMT+02:00 Simon Temple <si...@amalto.com>:

>
> The database I wish to replicate contains user information.  This information is not updated very frequently but is read often. <http://bit.ly/1Lqt8qy>
>

We use a simple nodejs script to manage replications in a similar (I
guess) case, it's build around follow and nano.
We do follow DB changes, when a database changes a continuous
replication for this DB is started and canceled again after a timeout.
A change to a db while the replication is running resets the timeout.
The replicated sequences are captured, so next time a replication is
started it is started with the correct "since" parameter.
This way, though each user got his own database, we keep the
concurrent running replications pretty low.

-- 
Stefan

Re: How to unsubscribe?

Posted by Geoff Bomford <ge...@comformark.com.au>.

Thanks Eri!

I had frequently changing data and without being able to delete and purge 
old data CouchDb 2.0.0 was not usable for me.

-----Original Message----- 
From: Eiri
Sent: Wednesday, April 12, 2017 09:14
To: user@couchdb.apache.org
Subject: Re: How to unsubscribe?

Hi Geoff,

Sorry to hear you stopped using Couch.

To unsubscribe just send an empty email to 
user-unsubscribe@couchdb.apache.org from your subscribed address. It is 
mentioned on http://couchdb.apache.org in section \u201cMailing lists"

Regards,
Eric

> On Apr 11, 2017, at 20:01, Geoff Bomford <ge...@comformark.com.au> 
> wrote:
>
> Can someone please remind me how to unsubscribe from this list?
>
> I can't find a link?
>
> I have stopped using CouchDb.
>

Re: How to unsubscribe?

Posted by Eiri <ei...@eiri.ca>.

Hi Geoff,

Sorry to hear you stopped using Couch.

To unsubscribe just send an empty email to user-unsubscribe@couchdb.apache.org from your subscribed address. It is mentioned on http://couchdb.apache.org in section “Mailing lists" 

Regards,
Eric

> On Apr 11, 2017, at 20:01, Geoff Bomford <ge...@comformark.com.au> wrote:
> 
> Can someone please remind me how to unsubscribe from this list?
> 
> I can't find a link?
> 
> I have stopped using CouchDb.
>

How to unsubscribe?

Posted by Geoff Bomford <ge...@comformark.com.au>.

Can someone please remind me how to unsubscribe from this list?

I can't find a link?

I have stopped using CouchDb.

Re: How scalable is replication?

Posted by Adam Kocoloski <ko...@apache.org>.

Hi Simon, it is definitely possible for a single cluster to manage thousands of replication jobs simultaneously — we have done this in production — but it does introduce scalability challenges and quite a bit of computational overhead. There’s a lot of work happening to improve CouchDB’s handling of large numbers of replications right now in https://issues.apache.org/jira/browse/COUCHDB-3324; Nick Vatamaniuc recently summarized the effort on the dev@couchdb mailing list:

http://mail-archives.apache.org/mod_mbox/couchdb-dev/201704.mbox/browser

Cheers, Adam

> On Apr 11, 2017, at 4:45 AM, Simon Temple <si...@amalto.com> wrote:
> 
> I'm searching for information about replication scalability, has anyone deployed replication across hundreds or even thousands of instances?
> 
> Can I realistically expect a single cluster to act as a replication point for a thousand replicas?
> 
> The database I wish to replicate contains user information.  This information is not updated very frequently but is read often. <http://bit.ly/1Lqt8qy>
> 
> TIA
> 
> Simon
> <http://bit.ly/1Lqt8qy>
> <http://bit.ly/1Lqt8qy> <http://bit.ly/1Lqt8qy>