Hello guys!
I am testing the repair inc in my custer cassandra. I am doing my test over
these tables
*CREATE TABLE pns_nonreg_bench.cf3* (
s text,
sp int,
d text,
dp int,
m map<text, text>,
t timestamp,
PRIMARY KEY (s, sp, d, dp)
) WITH CLUSTERING ORDER BY (sp ASC, d ASC, dp ASC)
AND compaction = {'class': 'org.apache.cassandra.db.compaction.
*LeveledCompactionStrategy*'}
AND compression = {'sstable_compression':
'org.apache.cassandra.io.compress.*SnappyCompressor*'}
*CREATE TABLE pns_nonreg_bench.cf1* (
ise text PRIMARY KEY,
int_col int,
text_col text,
ts_col timestamp,
uuid_col uuid
) WITH bloom_filter_fp_chance = 0.01
AND compaction = {'class': 'org.apache.cassandra.db.compaction.
*LeveledCompactionStrategy*'}
AND compression = {'sstable_compression':
'org.apache.cassandra.io.compress.*SnappyCompressor*'}
*table cf1 Space used (live): 665.7 MB*
*table cf2*
* Space used (live): 697.03 MB*
It happens that when I do repair -inc -par on theses tables, *cf2 got a
pick of 3k sstables*. When the repair finish, it takes 30 min or more to
finish all the compactations and return to 6 sstable.
I am a little concern about if this will happen on production. is it normal?
Saludos
Jean Carlo
"The best way to predict the future is to invent it" Alan Kay
