ajkr
commented
6 years ago It looks like some of your column families are being flushed aggressively while others aren't getting flushed at all. RocksDB interleaves data from all column families in the WAL file, so we can't archive/delete a WAL until all column families have flushed that WAL's data.
Does the total size of the WALs in your DB directory exceed 1GB (your max_total_wal_size)? When it does, we should automatically trigger flushes in such a way that we're able to drop old WALs and reclaim space. You can try reducing max_total_wal_size to see this more easily. Let us know if it's not happening.
kapitan-k
Expected behavior
Expecting RocksDB to delete wal files.
Actual behavior
After some time of usage deletion stops.
Steps to reproduce the behavior
Could you please check my options to be sane? As you can see below, I set for example: WAL_ttl_seconds=60, WAL_size_limit_MB=360, max_total_wal_size=1073741824, delete_obsolete_files_period_micros=10000 I expect wal files to be deleted relatively early. Deletion also does not happen when above options are changed to for example: WAL_ttl_seconds=0, WAL_size_limit_MB=0, max_total_wal_size=0,
Here is my LOG for a normal DB open atm: