UPDATE: The instructions here are no longer necessary! Resizing the disk image is now possible right from the UI since Docker for Mac Version 17.12.0-ce-mac49 (21995).
If you are getting the error: No space left on device
Configuring the qcow2 size cap is possible in the current versions:
# my disk is currently 64GiB
| #!/usr/bin/env python | |
| import re | |
| import sys | |
| REGEX_KEYSPACE = re.compile(r'^Keyspace: (.*)|^Keyspace : (.*)') | |
| REGEX_TABLE = re.compile(r'^\t\tTable: (.*)') | |
| REGEX_READ_CNT = re.compile(r'^\t\tLocal read count: (.*)') | |
| REGEX_WRITE_CNT = re.compile(r'^\t\tLocal write count: (.*)') | |
| ## |
| [s3] | |
| #s3 bucket name | |
| bucket_name = my_backups | |
| download_threads = 6 | |
| # other s3 access is defined in the default aws cli settings file | |
| [opscenter] | |
| backup_job_uuid = # get this from s3 bucket | |
| [node] |
Here is an example of several different kinds of C* tombstones. For reference, they are:
The obvious culprit of tombstone creation is DELETE, but there are other - less obvious - sources of the tombstone. Let’s see exacly what happens on disk when a tombstone is created. It's funny to say that a tombstone is created... aren't we deleting things? Remember, everything in C* is a write! A DELETE operation writes another sstable entry with a newer timestamp than all the other entries... and the most recent timestamp wins!
I’ve created a DataStax Studio notebook that complements this gist. You should be able to download it and run it for yourself :-) nodetool and sstabledump commands need to be run from a terminal on the node(s) you're working with.