> Also, if we repaired once successfully, will the next repair process take
a more reasonable time?
Depends on if there was a lot of inconsistent data to repair in the first
place. Also full repairs or incremental?
Repairs are complicated and tricky to get working efficiently. If you're
using
Thanks, we'll try delete range of rows as it seems to fit our scenario.
One more question, as you mentioned "repair often" - and we have seen that
several times, the official doc, representations, blogs, etc.
But when we repair a column family sized to terabytes on a cluster with ~30
nodes, it
Delete using as few tombstones as possible (deleting the whole partition is
better than deleting a row; deleting a range of rows is better than deleting
many rows in a range).
Repair often and lower gc_grace_seconds so the tombstones can be collected more
frequently
--
Jeff Jirsa
> On Jul
Hi there.
We have a keyspace containing tons of records, and deletions are used as
enforced by its business logic.
As the data accumulates, we are suffering from performance penalty due to
tombstones, still confusing about what could be done to minimize the harm,
or shall we avoid any deletions
