lewmelvin opened a new issue #1059: Automatic compaction of _global_changes doesn't work URL: https://github.com/apache/couchdb/issues/1059 <!--- Provide a general summary of the issue in the Title above --> 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. ## Expected Behavior <!--- If you're describing a bug, tell us what should happen --> Compaction of _global_changes should be triggered when the check_interval passes and the file and data sizes meet the parameters of the compaction configuration. In my testing, it doesn't get triggered. <!--- If you're suggesting a change/improvement, tell us how it should work --> ## Current Behavior <!--- If describing a bug, tell us what happens instead of the expected behavior --> Nothing happens. There is no error in the log for the configuration, yet the check_interval passes and no compaction event occurs. <!--- If suggesting a change/improvement, explain the difference from current behavior --> ## Possible Solution <!--- Not obligatory, but suggest a fix/reason for the bug, --> I contacted the CouchDB Users email list and Adam replied with the following: 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_couchdb_issues-3F&d=DwIFaQ&c=nulvIAQnC0yOOjC0e0NVa8TOcyq9jNhjZ156R-JJU10&r=jjIKqwApUzKCDY-o1Ex3afd4bksosuJsda_NnZShUUM&m=XHjiBSrSt89_WhJ4-9-2UpcbGcs9zvxIpJN-QXPCNBI&s=dRWvHDgKxwCB7lPHOIDib7jmUy9wVGLuDcG0j0N3R7s&e= 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 <!--- or ideas how to implement the addition or change --> ## Steps to Reproduce (for bugs) <!--- Provide a link to a live example, or an unambiguous set of steps to --> <!--- reproduce this bug. Include code to reproduce, if relevant --> 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 ## Context <!--- How has this issue affected you? What are you trying to accomplish? --> <!--- Providing context helps us come up with a solution that is most useful in the real world --> _global_changes grows a lot and fills my filesystem. Enabling compaction will keep this disk growth under control. ## Your Environment <!--- Include as many relevant details about the environment you experienced the bug in --> * Version used: CouchDB 2.0.0 * Browser Name and version: * Operating System and version (desktop or mobile): RHEL Linux 7.2 * Link to your project:
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
