couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Multiple database backup strategy
Date Tue, 15 Mar 2016 17:55:19 GMT

> On Mar 14, 2016, at 2:11 AM, javier@candeira.com wrote:
> 
> On 2016-03-14 13:40, Adam Kocoloski wrote:
> 
>>>> My current solution watches the global _changes feed and fires up a
>>>> continuous replication to an off-site server whenever it sees a change. If
>>>> it doesn't see a change from a database for 10 minutes, it kills that
>>>> replication. This means I only have ~150 active replications running on
>>>> average at any given time.
>>> How about instead of using continuous replications and killing them,
>>> use non-continuous replications based on _db_updates? They end
>>> automatically and should use fewer resources then.
>>> Best
>>> Jan
>>> --
>> In my opinion this is actually a design we should adopt for CouchDB’s
>> own replication manager. Keeping all those _changes listeners running
>> is needlessly expensive now that we have _db_updates.
>> Adam
> 
> I like Jan's solution, and I'm going to try and use it for a project, but it can't be
the only solution, at least for one of my cases. In this case I work with devices behind NAT
that need to pull data from updated remote databases with reasonably low latency.
> 
> The source database can't start a push replication on _db_updates, because it can't find
the target database behind NAT. "Pull" replications have to be started by the target database
(the NATted device), which doesn't know whether the source database is updated unless it's
on a continuous replication.

I’m missing something here Javier. A pull replication mediated on the target server should
still be able to remotely hit _db_updates on the source, shouldn’t it?

I do realize that there’s a potential permissions issue here, when the replication is executed
with sufficient privileges to read from the source database but not enough to hit _db_updates.

> Thanks for the high quality, high signal/noise list, btw. I don't usually say anything
because I don't think I have anything to add, but I always read with interest.

Agreed! I don’t get to spend as much time on CouchDB as I’d like, but I believe we’ve
established a nice balance between Pull Requests, JIRA and dev@ that allows people to participate
at whatever level makes the most sense. Cheers,

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