Cassandra manual major compaction changes frequency of minor compactions

1
votes

I am a little unclear about the following lines from the Datastax page on tuning cassandra compactions. Specifically they mention:

"Administrators can also initiate a major compaction through nodetool compact, which merges all SSTables into one. Though major compaction can free disk space used by accumulated SSTables, during runtime it temporarily doubles disk space usage and is I/O and CPU intensive. Also, once you run a major compaction, automatic minor compactions are no longer triggered frequently forcing you to manually run major compactions on a routine basis. So while read performance will be good immediately following a major compaction, it will continually degrade until the next major compaction is manually invoked. For this reason, major compaction is NOT recommended by DataStax." (http://www.datastax.com/docs/1.0/operations/tuning)

The two questions after reading this that came to my mind that I am trying to understand better are:

  1. Why would the major compaction that is triggered manually change the minor compaction interval / frequency? I am not quite sure I follow the underlying reason behind this.
  2. If I do need to run major compaction manually using nodetool, is it even possible and if so how can I revert back to ensure that the minor compaction intervals do not get affected as a result and are reset to the default behavior.

Thanks.

2
cassandradatastaxnodetool
Why are you looking at such an old doc? A Google hit? There have been many compaction changes and improvements since 1.0 and the docs now say something different: website-staging.dev.datastax.com/documentation/cassandra/2.1/… - catpaws
It was indeed a google hit @catpaws. I did not realize that it was such an old document until you pointed it out. However, I am unable to open your link above as it says I need authentication. Is there another reference you could point me to please ? - Rohit
Sorry about that, Rohit. This is what I meant to point to: datastax.com/documentation/cassandra/2.1/cassandra/dml/… - catpaws
Not a problem. Thanks for the new link. It does look a lot different, so that is not something I dont need to worry about. - Rohit

2 Answers

1
votes

Answer to your 2nd question:

"is it even possible and if so how can I revert back to ensure that the minor compaction intervals do not get affected"

[CASSANDRA_HOME]/bin/nodetool enableautocompaction

http://datastax.com/documentation/cassandra/2.0/cassandra/tools/toolsNodetool_r.html

1
votes

When major compaction is run, it will merge all SSTables into a single SSTable. For the most part what will happen is that newly created SSTable will be significantly larger than next SSTable that will be flushed from Memtable (defined with memtable_total_space_in_mb). If you are using size tiered compaction, cassandra will wait for 4 (again default) same size SSTables before it triggers next minor compaction. This delays next automatic minor compaction because Cassandra SStable created by major compaction will not be in line of other SSTables (memtable_total_space_in_mb). So Cassandra doesn't necessarily stops automatic minor compactions but frequency is now altered.

"is it even possible and if so how can I revert back to ensure that the minor compaction intervals do not get affected as a result and are reset to the default behavior." - For this you will have to break large sstable created as a result of major compaction. To do this, you can use utility called 'sstablesplit'.

https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsSSTableSplit.html