couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: _replicator DB
Date Wed, 19 May 2010 19:35:48 GMT
Grr, I tried to send this earlier today but just got a delivery failure notification.  Oh well,
here's the re-send

> Nice work Filipe.  This has been on the roadmap for a long time.  I have a couple of
questions:
> 
> 1) Does the patch insert the ID of the _local checkpoint doc into the _replicator doc?
 I think that would be pretty useful.
> 
> 2) Multiple identical replications running makes me very uneasy.  Does the patch also
break the behavior of /_replicate in that respect?
> 
> 3) Is the checkpoint ID generation algorithm backwards-compatible?  Or will users who
upgrade restart all replications from scratch?
> 
> I'm not sure I fully understand the max_dbs_open concern.  If you're hitting all_dbs_active
errors, that means a) you must have at least max_dbs_open concurrent requests for different
DBs running, or b) there's a bug in the ref counting code.  If it's a), that's a sign to increase
the max_dbs_open limit.
> 
> An infinite LRU timestamp for system DBs seems like a decent thing to do, but in this
case is it being used to hide a bug?  Best,
> 
> Adam

On May 19, 2010, at 10:35 AM, Jan Lehnardt wrote:

> Hi all,
> 
> Filipe, great work!
> 
> I think separate DBs make sense, but with a different angle.
> 
> Say I want to replicate all users to a new instance. I don't want to
> write a replication filter for that.
> 
> Replicating replication tasks sounds like a nice meta-CouchDB-
> programming thing I want to explore. People could benchmark
> their clusters by how many levels of replication it can take (think
> recursion :)
> 
> I see more "tasks" coming up in the future, say continuous compaction, 
> or compaction when certain events happen. For this, a single DB _tasks 
> would make sense to keep replication, compaction and whatever other 
> tasks we can come up with.
> 
> Users are not tasks, so they should be separate. Also, the _users db is 
> special cased in our auth-system, I'd rather not intermingle it with items 
> that don't need as high security (not saying you shouldn't be able to
> hide tasks, but it is a different thing).
> 
> Cheers
> Jan
> --
> 
> 
> On 19 May 2010, at 16:16, Filipe David Manana wrote:
> 
>> I also tend to prefer having two separate DBs. For now, there are 2 specific
>> resources (users and replications) but tomorrow we can have 3, 4, 5, etc.
>> 
>> However, a single _system DB would help with the max_open_dbs and _stats :)
>> 
>> 
>> 
>> On Wed, May 19, 2010 at 2:32 PM, Simon Metson <simonmetson@googlemail.com>wrote:
>> 
>>> +1
>>> 
>>> 
>>> On 19 May 2010, at 12:59, Sebastian Cohnen wrote:
>>> 
>>> having dedicated endpoints for specific resources sounds more reasonable
>>>> to me, than having a single endpoint for misc stuff. just my 2ct
>>>> 
>>>> 
>>>> On 19.05.2010, at 13:39, Dirkjan Ochtman wrote:
>>>> 
>>>> On Wed, May 19, 2010 at 13:13, Robert Dionne
>>>>> <dionne@dionne-associates.com> wrote:
>>>>> 
>>>>>> This sounds like a good approach, if I get the gist of it, it makes
the
>>>>>> replication state persistent. We also have a _users db now, is this
a good
>>>>>> time to think about consolidating and having one _system database
?
>>>>>> 
>>>>> 
>>>>> I too like the proposal, but I'd also prefer a single _system db
>>>>> rather than a bunch of specific databases.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Dirkjan
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> -- 
>> Filipe David Manana,
>> fdmanana@gmail.com
>> 
>> "Reasonable men adapt themselves to the world.
>> Unreasonable men adapt the world to themselves.
>> That's why all progress depends on unreasonable men."
> 


Mime
View raw message