Hiya Melvin, this looks like a bug. I think what’s happening is the compaction daemon is walking the list of database *shards* on the node and comparing those names directly against the keys in that config block. The shard files have internal names like
shards/00000000-1fffffff/_global_changes.1512750761 If you want to test this out you could look for the full path to one of your _global_changes shards and supply that as the key instead of just “_global_changes”. Repeating the config entry for every one of the shards could also be a workaround for you until we get this patched. Can you file an issue for it at https://github.com/apache/couchdb/issues? By the way, releases prior to 1.7.1 and 2.1.1 have a fairly serious security vulnerability, it’d be good if you could upgrade. Cheers, Adam > On Dec 6, 2017, at 2:21 PM, [email protected] wrote: > > Hi, > > I'm using couchdb 2.0.0 on RHEL 7.2 and I'm looking to configure automatic > compaction of _global_changes but I can't seem to get it to work. I've > checked the file size and data size of the _global_changes database so I know > the criteria I've specified have been met. I don't get an error upon couchdb > startup, but nothing happens. When I tried setting a _default compaction > rule, then compaction does happen for all databases including > _global_changes. Any ideas? I hope I'm just missing something obvious. > Please let me know if any more detail is needed. > > This is what I have in local.ini that does not work: > [compactions] > _global_changes = [{db_fragmentation, "70%"}] > > Putting this into local.ini does work, but I don't want to compact all > databases: > [compactions] > _default = [{db_fragmentation, "70%"}] > > For the purposes of my testing, I've also added: > [compaction_daemon] > check_interval = 30 > > Thanks in advance!
