Hi Melvin, right, it needs to be the full path as in my example below:
> shards/-1fff/_global_changes.1512750761
i.e. you need to include the "shards/xx-yy/" piece as well.
It is a bit curious that you’ve got those 4 separate timestamps. Typically
you’d see all the shards with the s
I tried the workaround two different ways, and it doesn't seem to work either.
I have a 4 node cluster, and I added this:
[compactions]
_global_changes.1483029052 = [{db_fragmentation, "70%"}]
_global_changes.1483029075 = [{db_fragmentation, "70%"}]
_global_changes.1483029126 = [{db_fragmentation
Thanks Adam! I've submitted the following issue:
https://github.com/apache/couchdb/issues/1059
Thanks also for the tip on the security vulnerability. We'll upgrade to CouchDB
2.1.1 soon. Fortunately this is an internal database on a firewalled corporate
network so we have a bit more time.
---
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/-1fff/_global_changes.
