We’ve been having some issues with high disk usage, so we decided to delete some older records.
At first, we saw that the disk usage was going up, but it makes sense as Tombstones are created when deleting records (Storage Properties | Couchbase Docs)
Now, the questions are:
During compaction, Tombstones and the Records are physically removed from the disk, freeing up space, right?
How can I see the current configuration of auto-compaction? When I go to Buckets → Edit → Advanced Bucket Settings → Mark ‘Override the default auto-compaction settings’ somehow I feel like I am not looking at the current configuration, but a default one instead. Is this right? Or the only reason I have to mark that ‘override’ checkbox is because I am (presumably) using the default configuration?
How can I check if and when the auto-compaction ran or not? There is not a single mention in the logs shown in the Web UI. I found some information about auto-compaction in the info.log file, but I cannot say for sure whether this means it ran successfully or not.
Not having any information in front of “Compression” in the bucket means we are storing data with no compression at all?
The information I found in info.log file:
...
[ns_server:info,2023-07-17T14:06:15.593Z,ns_1@XXX.XXX.XXX.XXX:<0.31916.1301>:compaction_daemon:spawn_scheduled_kv_compactor:522]Start compaction of vbuckets for bucket events with config:
[{database_fragmentation_threshold,{30,undefined}},
{view_fragmentation_threshold,{30,undefined}},
{magma_fragmentation_percentage,50}]
[ns_server:info,2023-07-17T14:06:15.995Z,ns_1@XXX.XXX.XXX.XXX:<0.101.1302>:compaction_daemon:spawn_scheduled_views_compactor:548]Start compaction of indexes for bucket events with config:
[{database_fragmentation_threshold,{30,undefined}},
{view_fragmentation_threshold,{30,undefined}},
{magma_fragmentation_percentage,50}]
...
You are correct. By default, a bucket will use the “default” settings which you can view in the “Settings” page for the cluster overall: Auto-Compaction | Couchbase Docs
This is a bit tricky because Couchbase will run compaction on each vbucket file independently (1024 active and 1024*n replica where ‘n’ is the number of replicas you have configured for that bucket). I believe those messages in the info.log file are simply referring to the start of the compaction daemon rather than the actual compaction event. Because of what I said earlier, there would be potentially A LOT of log messages as we are compacting the files on an ongoing basis. If you want to specifically reclaim disk space, I would suggest triggering compaction manually (which is the same thing that gets triggered automatically).
There are a couple factors to “compression” with Couchbase:
Couchbase always compresses data on disk. With the Couchstore engine, this is on a per-document basis (using snappy compression). With Magma, it’s both per-document (using snappy) and block level (using LZ4)