[
https://issues.apache.org/jira/browse/CASSANDRA-7976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14386275#comment-14386275
]
Stefania commented on CASSANDRA-7976:
-------------------------------------
Verified {{index_interval}} on cassandra-2.0 and reproduced the problem, added
unit test.
Verified {{min_index_interval}} and {{max_index_interval}} on trunk and
cassandra-2.1 but could not reproduce.
The problem for 2.0 is that the index interval is not updated in
{{CFMetadata.apply()}}. As a consequence, the index interval was never changed,
this is clearly visible in the log file, despite what the cqlsh DESC command
shows. The reason why the initial DESC command shows an updated index interval
is that the migration manager pushes a schema change that was not correctly
applied.
When the index interval was changed into min and max on cassandra-2.1,
{{CFMetadata.apply()}} was fixed (verified on trunk).
The patch for 2.0 is here: https://github.com/stef1927/cassandra/commits/7976.
> Changes to index_interval table properties revert after subsequent
> modifications
> --------------------------------------------------------------------------------
>
> Key: CASSANDRA-7976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7976
> Project: Cassandra
> Issue Type: Bug
> Components: Config
> Environment: cqlsh 4.1.1, Cassandra 2.0.9-SNAPSHOT (built w/ `ccm` on
> Mac OS X 10.9.4 with Java 1.7.0_67 - more detail below)
> $ java -version
> java version "1.7.0_67"
> Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)
> $ mvn --version
> Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
> 2014-08-11T13:58:10-07:00)
> Maven home: /usr/local/Cellar/maven/3.2.3/libexec
> Java version: 1.7.0_67, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac"
> Reporter: Andrew Lenards
> Assignee: Stefania
> Labels: cql3, metadata
>
> It appears that if you want to increase the sampling in *-Summary.db files,
> you would change the default for {{index_interval}} table property from the
> {{128}} default value to {{256}} on a given CQL {{TABLE}}.
> However, if you {{ALTER TABLE}} after setting the value, {{index_interval}}
> returns to the default, {{128}}. This is unexpected behavior. I would expect
> the value for {{index_interval}} to not be affected by subsequent {{ALTER
> TABLE}} statements.
> As noted in Environment, this was seen with a 2.0.9-SNAPSHOT built w/ `ccm`.
> If I just use a table from one of DataStax documentation tutorials (musicdb
> as mdb):
> {noformat}
> 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'};
> {noformat}
> We've got {{128}} as expected.
> We alter it:
> {noformat}
> cqlsh:mdb> ALTER TABLE songs WITH index_interval = 256;
> {noformat}
> And the change appears:
> {noformat}
> 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'};
> {noformat}
> But if do another {{ALTER TABLE}}, say, change the caching or comment, the
> {{index_interval}} will revert back to {{128}}.
> {noformat}
> 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'};
> {noformat}
> It should be {{index_interval=256}}.
> I know that 2.1 will replace {{index_interval}}.
> I have not confirmed any behavior with {{min_index_interval}} nor
> {{max_index_interval}} (which is described in resolved #6379).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
