Perhaps https://issues.apache.org/jira/browse/CASSANDRA-9592 got compactions moving forward for you? This would explain the drop.
However, the discussion on https://issues.apache.org/jira/browse/CASSANDRA-9683 seems to be similar to what you saw and that is currently being investigated. On Fri, Jul 17, 2015 at 10:24 AM, Mike Heffner <m...@librato.com> wrote: > Hi all, > > I've been upgrading several of our rings from 2.1.6 to 2.1.8 and I've > noticed that after the upgrade our storage load drops significantly (I've > seen up to an 80% drop). > > I believe most of the data that is dropped is tombstoned (via TTL > expiration) and I haven't detected any data loss yet. However, can someone > point me to what changed between 2.1.6 and 2.1.8 that would lead to such a > significant drop in tombstoned data? Looking at the changelog there's > nothing that jumps out at me. This is a CF definition from one of the CFs > that had a significant drop: > > > describe measures_mid_1; > > CREATE TABLE "Metrics".measures_mid_1 ( > key blob, > c1 int, > c2 blob, > c3 blob, > PRIMARY KEY (key, c1, c2) > ) WITH COMPACT STORAGE > AND CLUSTERING ORDER BY (c1 ASC, c2 ASC) > AND bloom_filter_fp_chance = 0.01 > AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}' > AND comment = '' > AND compaction = {'class': > 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'} > AND compression = {'sstable_compression': > 'org.apache.cassandra.io.compress.LZ4Compressor'} > AND dclocal_read_repair_chance = 0.1 > AND default_time_to_live = 0 > AND gc_grace_seconds = 0 > AND max_index_interval = 2048 > AND memtable_flush_period_in_ms = 0 > AND min_index_interval = 128 > AND read_repair_chance = 0.0 > AND speculative_retry = '99.0PERCENTILE'; > > Thanks, > > Mike > > -- > > Mike Heffner <m...@librato.com> > Librato, Inc. > > -- ----------------- Nate McCall Austin, TX @zznate Co-Founder & Sr. Technical Consultant Apache Cassandra Consulting http://www.thelastpickle.com
