cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7976) Changes to index_interval table properties revert after subsequent modifications
Date Mon, 30 Mar 2015 06:30:53 GMT

    [ 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)

Mime
View raw message