_global_changes database best practices

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

Re: Running CouchDB 2.0 cluster in EC2

Thanks Joan, it makes sense. I'll have a look at stunnel, it may work if it has normal support for CRL check. thanks, --Vovan > On Jun 26, 2017, at 10:41 PM, Joan Touzet wrote: > > Sorry, it's been many years since I configured stunnel for use with > CouchDB, and I no

Re: _global_changes purpose

Ah, I see now. So, there's no guarantee in certain failure modes in clustered environment. I've got confused as in the documentation losing event sounded like something usual and highly probable which is not the case. Thanks for the explanation guys! --Vovan > On Jun 27, 2017, at 8:55 AM,

Re: _global_changes purpose

The guarantee on the per-DB _changes feed is much stronger — if you got a 201 or 202 HTTP response back on the updated documents will always show up in _changes eventually. It'd be nice if we could offer the same guarantee on _db_updates but there are some non-trivial technical challenges

Re: _global_changes purpose

Joan, thanks for the pointer to the documentation. Sorry for being annoying, I have one more question. The doc states the following: "Note: This was designed without the guarantee that a DB event will be persisted or ever occur in the _db_updates feed. It probably will, but it isn't

Re: _global_changes purpose

I'll update the docs. However, for now we have: --- When a database is created, deleted, or updated, a corresponding event will be persisted to disk (Note: This was designed without the guarantee that a DB event will be persisted or ever occur in the _db_updates feed. It probably will, but it