Re: cassandra_migration_wait

2020-01-13 Thread Ben Mills
Hi Reid,

Many thanks! Very helpful.

Will have a look at that source.

Ben



On Mon, Jan 13, 2020 at 2:08 PM Reid Pinchback 
wrote:

> I can’t find it anywhere either, but I’m looking at a 3.11.4 source
> image.  From the naming I’d bet that this is being used to feed the
> cassandra.migration_task_wait_in_seconds property.  It’s already coded to
> have a default of 1 second, which matches what you are seeing in the shell
> script var.  The relevant Java source is
> org.apache.cassandra.service.MigrationManager, line 62.
>
>
>
> *From: *Ben Mills 
> *Reply-To: *"user@cassandra.apache.org" 
> *Date: *Monday, January 13, 2020 at 1:59 PM
> *To: *"user@cassandra.apache.org" 
> *Subject: *cassandra_migration_wait
>
>
>
> *Message from External Sender*
>
> Greetings,
>
>
>
> We are running Cassandra 3.11.2 in Kubernetes and use a run.sh to set some
> environment variables and a few other things.
>
>
>
> This script includes:
>
>
>
> CASSANDRA_MIGRATION_WAIT="${CASSANDRA_MIGRATION_WAIT:-1}"
>
>
>
> setting this environment variable to "1". I looked for documentation on
> this but cannot seem to find it anywhere. Anyone know what this is
> configuring and what the value implies?
>
>
>
> Thanks in advance for your help.
>
>
>
> Ben
>
>
>


Re: cassandra_migration_wait

2020-01-13 Thread Reid Pinchback
I can’t find it anywhere either, but I’m looking at a 3.11.4 source image.  
From the naming I’d bet that this is being used to feed the 
cassandra.migration_task_wait_in_seconds property.  It’s already coded to have 
a default of 1 second, which matches what you are seeing in the shell script 
var.  The relevant Java source is 
org.apache.cassandra.service.MigrationManager, line 62.

From: Ben Mills 
Reply-To: "user@cassandra.apache.org" 
Date: Monday, January 13, 2020 at 1:59 PM
To: "user@cassandra.apache.org" 
Subject: cassandra_migration_wait

Message from External Sender
Greetings,

We are running Cassandra 3.11.2 in Kubernetes and use a run.sh to set some 
environment variables and a few other things.

This script includes:

CASSANDRA_MIGRATION_WAIT="${CASSANDRA_MIGRATION_WAIT:-1}"

setting this environment variable to "1". I looked for documentation on this 
but cannot seem to find it anywhere. Anyone know what this is configuring and 
what the value implies?

Thanks in advance for your help.

Ben



cassandra_migration_wait

2020-01-13 Thread Ben Mills
Greetings,

We are running Cassandra 3.11.2 in Kubernetes and use a run.sh to set some
environment variables and a few other things.

This script includes:

CASSANDRA_MIGRATION_WAIT="${CASSANDRA_MIGRATION_WAIT:-1}"

setting this environment variable to "1". I looked for documentation on
this but cannot seem to find it anywhere. Anyone know what this is
configuring and what the value implies?

Thanks in advance for your help.

Ben


Re: [E] bug in cluster key push down

2020-01-13 Thread Hannu Kröger
No, I think it was originally correct.

If partition key has multiple parts, then you need parenthesis around parts of 
partition key.

Hannu

> On 13. Jan 2020, at 14.30, Saha, Sushanta K 
>  wrote:
> 
>> primary key (partition, clustering1, clustering2)
>> 
>> So, the partitioning key has three columns. You need to specify values for 
>> all three columns. For clustering columns, you need another parenthesis like 
>> primary key (partition, (clustering1, clustering2))
>> 
>>  Sushanta
> 
> On Sun, Jan 12, 2020 at 10:52 AM Jeff Jirsa  > wrote:
> Can you open a jira so someone can investigate ? It’s probably just a logging 
> / visibility problem, but we should confirm 
> 
> Sent from my iPhone
> 
>> On Jan 12, 2020, at 6:04 AM, onmstester onmstester 
>>  wrote:
>> 
>> 
>> Using Apache Cassandra 3.11.2, defined a table like this:
>> 
>> create table my_table(
>>partition text,
>>clustering1 int,
>>   clustering2 text,
>>   data set,
>> primary key (partition, clustering1, clustering2))
>> 
>> and configured slow queries threshold to 1ms in yaml to see how queries 
>> passed to cassandra. Query below:
>> 
>> select * from my_table where partition='a' and clustering1= 1 and 
>> clustering2='b'
>> 
>> would be like this in debug.log of cassandra:
>> 
>> select * from my_table where partition='a' LIMIT 100>  (it means that the 
>> two cluster key restriction did not push down to storage engine and the 
>> whole partition been retrieved)
>> 
>> but this query:
>> 
>> select * from my_table where partition='a' and clustering1= 1
>> 
>> would be 
>> 
>> select * from my_table where partition='a' and clustering1= 1 LIMIT 100> 
>> (single cluster key been pushed down to storage engine)
>> 
>> 
>> So it seems to me that, we could not restrict multiple clustering keys in 
>> select because it would retrieve the whole partition ?!
>> Sent using Zoho Mail 
>> 
>> 
>> 
>> 
> 
> 
> -- 
> 
> Sushanta Saha|MTS IV-Cslt-Sys Engrg|WebIaaS_DB Group|HQ - VerizonWireless 
> O 770.797.1260  C 770.714.6555 Iaas Support Line 949-286-8810
> 



Re: [E] Re: bug in cluster key push down

2020-01-13 Thread Saha, Sushanta K
*primary key (partition, clustering1, clustering2)*

So, the partitioning key has three columns. You need to specify values for
all three columns. For clustering columns, you need another parenthesis
like *primary key (partition, (clustering1, clustering2))*

* Sushanta*


On Sun, Jan 12, 2020 at 10:52 AM Jeff Jirsa  wrote:

> Can you open a jira so someone can investigate ? It’s probably just a
> logging / visibility problem, but we should confirm
>
> Sent from my iPhone
>
> On Jan 12, 2020, at 6:04 AM, onmstester onmstester
>  wrote:
>
> 
> Using Apache Cassandra 3.11.2, defined a table like this:
>
>
> *create table my_table(*
>*partition text,*
>*clustering1 int,*
>
> *clustering2 text,*
>
> *data set,*
> *primary key (partition, clustering1, clustering2))*
>
> and configured slow queries threshold to 1ms in yaml to see how queries
> passed to cassandra. Query below:
>
> *select * from my_table where partition='a' and clustering1= 1 and
> clustering2='b'*
>
> would be like this in debug.log of cassandra:
>
> *select * from my_table where partition='a' LIMIT 100>  (it means that the
> two cluster key restriction did not push down to storage engine and the
> whole partition been retrieved)*
>
> but this query:
>
> *select * from my_table where partition='a' and clustering1= 1*
>
> *would be *
>
> *select * from my_table where partition='a' and clustering1= 1 LIMIT 100>
> (single cluster key been pushed down to storage engine)*
>
>
> *So it seems to me that, we could not restrict multiple clustering keys in
> select because it would retrieve the whole partition ?!*
>
> Sent using Zoho Mail
> 
>
>
>
>

-- 

*Sushanta Saha|*MTS IV-Cslt-Sys Engrg|WebIaaS_DB Group|HQ -
* VerizonWireless O 770.797.1260  C 770.714.6555 Iaas Support Line
949-286-8810*