Skip to content

Instantly share code, notes, and snippets.

@lenards
Created September 17, 2014 23:25
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save lenards/8a9a4ee134e3b1e7ff63 to your computer and use it in GitHub Desktop.
Save lenards/8a9a4ee134e3b1e7ff63 to your computer and use it in GitHub Desktop.
Issue changing `index_interval` on a table.

I had a customer ask me about modifying index_interval. They want to increase the sampling with *-Summary.db files, so they're trying to increase from the 128 default value to 256.

But what they're experiencing is that if they ALTER TABLE after setting the value, index_interval returns to 128.

I reproduced it with C* 2.0.9:

$ ccm node1 cqlsh 
Connected to simple1 at 127.0.0.1:9160.
[cqlsh 4.1.1 | Cassandra 2.0.9-SNAPSHOT | CQL spec 3.1.1 | Thrift protocol 19.39.0]

If I just use a table from one of our documentation tutorials (musicdb as mdb):

cqlsh:mdb> DESC TABLE songs;

CREATE TABLE songs (
  id uuid,
  album text,
  artist text,
  data blob,
  reviews list<text>,
  tags set<text>,
  title text,
  venue map<timestamp, text>,
  PRIMARY KEY ((id))
) WITH
  bloom_filter_fp_chance=0.010000 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.100000 AND
  gc_grace_seconds=864000 AND
  index_interval=128 AND
  read_repair_chance=0.000000 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  default_time_to_live=0 AND
  speculative_retry='99.0PERCENTILE' AND
  memtable_flush_period_in_ms=0 AND
  compaction={'class': 'SizeTieredCompactionStrategy'} AND
  compression={'sstable_compression': 'LZ4Compressor'};

We've got 128 as expected.

We alter it:

cqlsh:mdb> ALTER TABLE songs WITH index_interval = 256; 

And the change appears in our next DESCRIBE.

cqlsh:mdb> DESC TABLE songs;

CREATE TABLE songs (
  id uuid,
  album text,
  artist text,
  data blob,
  reviews list<text>,
  tags set<text>,
  title text,
  venue map<timestamp, text>,
  PRIMARY KEY ((id))
) WITH
  bloom_filter_fp_chance=0.010000 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.100000 AND
  gc_grace_seconds=864000 AND
  index_interval=256 AND
  read_repair_chance=0.000000 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  default_time_to_live=0 AND
  speculative_retry='99.0PERCENTILE' AND
  memtable_flush_period_in_ms=0 AND
  compaction={'class': 'SizeTieredCompactionStrategy'} AND
  compression={'sstable_compression': 'LZ4Compressor'};

But if do another ALTER TABLE, say, change the caching or comment, the index_interval will revert back to 128.

cqlsh:mdb> ALTER TABLE songs WITH caching = 'none'; 
cqlsh:mdb> DESC TABLE songs; 

CREATE TABLE songs (
  id uuid,
  album text,
  artist text,
  data blob,
  reviews list<text>,
  tags set<text>,
  title text,
  venue map<timestamp, text>,
  PRIMARY KEY ((id))
) WITH
  bloom_filter_fp_chance=0.010000 AND
  caching='NONE' AND
  comment='' AND
  dclocal_read_repair_chance=0.100000 AND
  gc_grace_seconds=864000 AND
  index_interval=128 AND
  read_repair_chance=0.000000 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  default_time_to_live=0 AND
  speculative_retry='99.0PERCENTILE' AND
  memtable_flush_period_in_ms=0 AND
  compaction={'class': 'SizeTieredCompactionStrategy'} AND
  compression={'sstable_compression': 'LZ4Compressor'};

It should be index_interval=256.

Other table metadata changes (like the caching change) do not revert after a simple ALTER TABLE:

cqlsh:mdb> ALTER TABLE songs WITH comment = 'huh'; 

cqlsh:mdb> DESC TABLE songs;

CREATE TABLE songs ( id uuid, album text, artist text, data blob, reviews list, tags set, title text, venue map<timestamp, text>, PRIMARY KEY ((id)) ) WITH bloom_filter_fp_chance=0.010000 AND caching='NONE' AND comment='huh' AND dclocal_read_repair_chance=0.100000 AND gc_grace_seconds=864000 AND index_interval=128 AND read_repair_chance=0.000000 AND replicate_on_write='true' AND populate_io_cache_on_flush='false' AND default_time_to_live=0 AND speculative_retry='99.0PERCENTILE' AND memtable_flush_period_in_ms=0 AND compaction={'class': 'SizeTieredCompactionStrategy'} AND compression={'sstable_compression': 'LZ4Compressor'};


Is there some way of explaining this?  Should I be filing as a bug in CASSANDRA JIRA? (I have search the Apache Cassandra JIRA, and I know ``index_interval`` is replaced with min/max in 2.1, not sure if that makes this a "please update" for the resolution)


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment