And as a corollary to this, we are enabling the compaction daemon by
default shortly. I expect this change to be enabled for the upcoming
CouchDB 2.1 release.
https://github.com/apache/couchdb/pull/624
-Joan
----- Original Message -----
From: "Robert Samuel Newson" <[email protected]>
To: "user" <[email protected]>
Sent: Wednesday, 5 July, 2017 7:07:54 PM
Subject: Re: _global_changes database best practices
Hi,
Sorry.
The global database schema is well designed and the database should compact
down very neatly, so be sure you _are_ compacting it regularly. If it's still a
problem, just delete it, it's completely optional. Obviously you lose the
/_db_updates feature without the backing store, but everything else works.
B.
> On 5 Jul 2017, at 23:47, Vladimir Kuznetsov <[email protected]> wrote:
>
> Hi guys,
>
> Can somebody please answer this?
>
> thanks
> --Vovan
>
>> On Jun 29, 2017, at 3:37 PM, Vladimir Kuznetsov <[email protected]> wrote:
>>
>> Hi guys,
>>
>> Can somebody please answer this? I'd really appreciate If somebody could
>> provide any good pointer to the documentation about _global_changes
>> internals. I think it'd be useful for many people. Basic answers like at
>> what circumstances _global_changes is being updated(I noticed it's not
>> always updated on document insert), does it provide any expiration or
>> self-management capabilities to get it's size under control, any other
>> things to keep in mind...
>>
>> thanks,
>> --Vovan
>>
>>
>>> On Jun 27, 2017, at 1:09 PM, Vladimir Kuznetsov <[email protected]> wrote:
>>>
>>> Hi guys,
>>>
>>> I have thousands of databases in Couchdb 2 cluster and I get them
>>> constantly updated. Each database is also rotated on monthly basis i.e. I'm
>>> keeping dbs for the last several months, then just remove oldes ones. I
>>> suppose _global_changes database is going to extensively grow as databases
>>> are going to be continuously created/updated/deleted. Does _global_changes
>>> database provide any mechanism of automatic data expiration? Or is it
>>> better to disable _global_changes database with such a usage pattern?
>>>
>>> thanks,
>>> --Vovan
>>
>
