Hello Charl,
Everything looks as expected in the vnode status and the logs. Feel free to run
`bitcask:merge(/PATH/TO/PARTITION)` for other partitions on the node(s) to
reclaim space.
Let us know how things go.
Thanks,
--
Brian Sparrow
Developer Advocate
Basho Technologies
Sent with
Hi,
We have a 8-node riak v1.4.0 cluster writing data to bitcask backends.
We've recently started running out of disk across all nodes and so
implemented a 30-day sliding window data retention policy. This policy
is enforced by a go app that concurrently deletes documents outside
the window.
Hi Charl,
The problem is that even though documents seem to no longer be
available (doing a GET on a deleted document returns an expected 404)
the disk usage is not seeming reducing much and has currently been at
~80% utilisation across all nodes for almost a week.
When you delete a document,
riak-admin vnode-status can be used to get information about the
number of bitcask files, their fragmentation and dead bytes, but since
it uses a lot of blocking vnode commands, it can spike latencies, so
should only be used off-peak.
On Mon, Sep 16, 2013 at 7:36 AM, Alex Moore amo...@basho.com
Hey Charl,Thanks for the logs and the config. I do see bitcask merges occurring in your console.log, so it's not stuck.I would recommend running "riak-admin vnode-status" during an off-peak time like Evan mentioned, that way we can see what your dead bytes/fragmentation levels look like. This will
