No, we haven't changed RF, but it's been a very long time since we repaired last, so we're guessing this is an effect of not running repair regularly, and that doing it regularly will fix it. It would just be nice to know.

Also, running major compaction after the repair made the data size shrink back to what it was before, soe clearly a lot of junk data was sent over on that repair, most probably tombstones of some kind, as discussed in the other thread.


On Thu, Nov 8, 2012 at 1:53 PM, Alain RODRIGUEZ <> wrote:
Did you change the RF or had a node down since you repaired last time ?

2012/11/8 Henrik Schröder <>
No, we're not using columns with TTL, and I performed a major compaction before the repair, so there shouldn't be vast amounts of tombstones moving around.

And the increase happened during the repair, the nodes gained ~20-30GB each.


On Thu, Nov 8, 2012 at 12:40 PM, horschi <> wrote:

is it possible that your repair is overrepairing due to any of the issues discussed here: ?

I've seen repair increasing the load on my cluster, but what you are describing sounds like a lot to me.

Does this increase happen due to repair entirely? Or was the load maybe increasing gradually over the week and you just checked for the first time?


On Thu, Nov 8, 2012 at 11:55 AM, Henrik Schröder <> wrote:

We recently ran a major compaction across our cluster, which reduced the storage used by about 50%. This is fine, since we do a lot of updates to existing data, so that's the expected result.

The day after, we ran a full repair -pr across the cluster, and when that finished, each storage node was at about the same size as before the major compaction. Why does that happen? What gets transferred to other nodes, and why does it suddenly take up a lot of space again?

We haven't run repair -pr regularly, so is this just something that happens on the first weekly run, and can we expect a different result next week? Or does repair always cause the data to grow on each node? To me it just doesn't seem proportional?